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TEST  PROGRAM  SET  (TP'"'  DESIGN  GUIDE 


FOREWORD 

This  document  prepared  for  the  United  States  Army  Electronics  Command, 

Fort  Monmouth,  New  Jersey,  under  Contract  DAABQ7-77-C-2727  is 
intended  to  serve  as  an  aid  in  developing  definitive  Test  Program  Sets  (TPS's). 

The  objectives  of  the  design  guide  are  to  support  specific  basic  parameters 
for  mission  vehicle  operational  readiness  through  the  development  of 
effective,  efficient  and  economical  methods  of  mechanizing  the  tools 
required  for  supporting  and  repairing  electronic  components. 

Dynamic  Sciences  International,  Inc.  (DSII)  has  reviewed  a significant  data 
base,  established  by  the  military  and  industry,  and  has  arrived  at  the  con- 
clusions contained  in  this  report. 

The  intent  of  this  study  is  to  identify  cost  drivers  and  areas  of  responsibility 
that  will  provide  the  Army  with  a basis  for  TPS  development.  This  develop- 
ment will  lend  itself  towards  cost  effective  measures  that  will  enhance  system 
effectiveness. 
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INTRODUCTION 

PURPOSE 

This  Design  Guide  has  been  prepared  to  provide  consistent  and  uniform 
requirements  and  guidelines  for  planning  and  specifying  Test  Program  Sets 
. *S's)  for  Units  Under  Test  (UUT's).  The  Design  Guide  will  also  provide 
both  design  and  evaluation  criteria  to  ensure  acquisition  of  complete 
and  uniform  TPS's.  Additionally/  it  covers  the  prime  drivers  needed  to 
implement  the  development  of  TPS's. ' Contained  in  this  guide  are: 

a.  Planning  the  development  of  TPS's  for  the  purpose  of 
specifying  their  total  requirements  in  detail. 

b.  Planning  the  development  of  TPS's  for  the  purpose  of 
understanding  and  applying  developed  information  in 
the  preparation  of  TPS's. 

c.  Evaluation  of  TPS's  development  planning  and  imple- 
mentation during  the  design  and  generation  of  TPS's. 

d.  Evaluation  accessment  of  TPS's  to  ensure  acquisition 
and/or  development  of  complete  and  uniform  products. 

If  properly  implemented,  the  TPS  Design  Guide  will  provide  the  Army  with 
well  planned  and  well  constructed  test  programs  that  satisfy  the  test  support 
requirements  at  the  following  Level  of  Repairs  (LOR's): 


a.  Organizational 


b.  General  Support 

c . Depot 

d.  Manufacturer  (Vendor) 

Implementation  of  the  TPS  Design  Guide  has  the  capability  of  achieving  the 
fol  lowi  ng : 

a.  Providing  a system  that  when  motivated  to  completion 
can  allow  a proper  understanding  of  the  tasks  to  be 
performed  in  support  of  TPS's. 

b.  Providing  the  tools  needed  to  make  the  SYSTEM  work. 

c.  Providing  concepts  applicable  to  improving  the  TPS's 

system  requirements. 

d.  Describing  the  effects  of  implementation  of  a TPS 
design  guide  in  terms  of  capitalization  of  existing 
personnel  and  organizational  method  of  operation. 

The  foregoing  (a.  through  d.)  describe  what  are  considered  to  be  the  real 
drivers  in  the  development  of  the  TPS  Design  Guide.  The  contracted 
elements  to  be  provided  will  have  the  capability  to  assist  in: 

a.  Planning  TPS's 

% 

b.  Preparing  specifications  for  TPS's 

c.  Providing  engineering  guides  for  the  preparation  of  TPS's 

d.  Providing  engineering  guides  for  the  accessment  of  TPS's 

! 

. 
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DESIGN  GUIDE  PROJECT 

The  Design  Guide  Project  has  been  performed  in  three  (3)  development 
phases  and  is  divided  into  five  (5)  planning  cetegories  of  titled  structure. 

Specific  Contractual  Requirements 

The  guide  has  been  developed  in  compliance  with  the  following  contractual 
terms: 

a.  Support  concepts,  automatic  test  design  considerations, 
test  program  set  design,  interface  device  design,  code 
and  compile,  integration  and  acceptance  testing. 

b.  Planned  and  existing  ATE  have  been  reviewed.  The 
state-of-the  -art  in  electronic  equipment  design  has 
been  reviewed  (in  both  UUT's  and  ATE's)  and  the 
changing  needs  for  ATE  has  been  projected  from  the 
present  through  five  (5)  year  increments  through  1988. 

c.  This  guide  will  serve  as  a simplified  reference,  for 
information  selection  to  major  support  levels  for  TPS 
development  and  application.  Topics  such  as  data 
collection,  data  analysis,  interface  design,  program- 
ming techniques,  integration,  program  verification, 
fault  insertion  and  acceptance  testing,  documentation 
and  configuration  control  will  be  discussed  in  the 
following  sections. 

Compliance  with  each  of  the  contract's  terms  has  been 
met  within  the  body  of  the  guide  with  easy  access  and 
reference  to  the  reader  as  well  as  a TPS's  development 
planning  user. 


.] 
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1.2.2  The  Development  Phases 


1 .2.2.1  Phase  1 - Consists  of  a thorough  research  and  perusal  of  all  available 
documentation,  including  papers,  reports,  specifications,  standards,  etc. 
Phase. 1 was  not  limited  to  documentation  data  but  also  included  presenta- 
tions, meetings  and  discussions  with  personnel  of  varied  expertise  in  the 
fields  of  testing,  electronics,  ATE  and  TPS  development.  This  included 
hardware,  test  software,  operating  systems,  higher  order  language,  on- 
line edit  and  compile,  and  human  engineering.  The  content  of  these 
meetings  and  discussions  appears  throughout  the  guide. 

1 .2.2.2  Phase  2 - Consists  of  the  deveiopmeht  of  a methodology  for  absorbing 
and  collating  all  the  data  made  available  and  documenting  it  in  a format 
from  which  the  guide  could  be  systematically  generated. 

1 .2.2.3  Phase  3 - Consists  of  mechanizing  the  information  and  formats  estcfclished 
in  Phases  1 and  2 into  the  required  TPS  Design  Guide. 

1.2.3  The  Planning  Categories 

The  preceding  establishes  the  planning  checklist  categories  of  the  guide 


as  follows: 

1. 

Support  Level 

2. 

Testabi  lity/Bui  It-ln-Test 

3. 

ATE  Factors 

4. 

UUT  Data  Definition 

5. 

Design  Review  Requirements 
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"Configuration  Management"  is  addressed  throughout  the  entire  text,  and 
specifically  in  Section  XI. 


1.3  ASSUMPTIONS 

The  foundation  of  the  guide  reports  is  based  on  the  following: 

a.  That  the  guide  will  be  used  by  engineers  and 
managers  who  understand  the  stringent  require- 
ments of  TPS  development. 

b.  That  only  a partial  implementation  of  the  guide 
will  be  used  on  certain  occasions. 
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SECTION  II 


2.0  LEVEL  OF  REPAIR 

2.1  SCOPE 

This  section  deals  with  the  first  system  level  element  requiring  test 
definition  and/or  trade  study  to  determine  the  proper  level  at  which 
the  Unit  Under  Test  (UUT)  should  be  supported  and  what  diagnostic/ 
isolation  criteria  may  be  expected.  The  product  of  this  section  is  a 
checklist  which  will  identify  the  level  of  support  based  on  the  UUT's 
ability  to  be  tested  and  the  required  or  available  test  equipment. 

2.2  GENERAL 

Ideally,  an  electronic  system  could  be  designed  to  diagnose  itself 
through  a combination  of  Bui  It- In-Test  hardware  and  software  such  that 
a failure  could  be  isolated  to  a single  sub-assembly  at  the  organizational 
level.  This  would  require  only  two  (2)  organic  levels  of  support.  Organi- 
zational and  Depot.  Inherent  in  this  would  be  the  elimination  of  the 
general  (Intermediate)  Support  level  and  the  Return -to- Vendor  for  Repair 
and  thereby  eliminate  logistic  problems  these  two  repair  levels  cause. 

Realistically,  this  approach  exists  only  on  rare  occasions.  Until  electronic 
systems  are  truly  designed  for  testability  and  present  untestable  systems 
are  purged  from  the  inventory,  actions  must  take  place  that  will  allow 
the  best  technical  and  cost  related  decisions  possible  within  our  present 
and  near  term  projected  test  environment. 

Checks  and  balances  of  whefe  and  how  to  test  and  support  electronic 
systems  is  dependent  on  a myriad  of  complex  technical  and  cost  factors. 
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The  following  discussion  is  provided  to  give  insight  into  those  factors  which 
allow  a procurement  agency  to  specify  the  proper  level  of  support  and  test 
isolation  criteria  for  a given  electronic  system  and  its  sub-assemblies. 


Discussions  in  this  section  assume  that  (a)  some  testability  design  require- 
ments were  imposed  on  the  supplier  during  procurement,  and  (b)  that  some 
form  of  Logistic  Support  Analysis  (LSA)  has  been  performed  to  determine  a 
preliminary  support/test  level.  In  the  event  either  or  neither  were  accom 
plished,  this  section  provides  insight  into  a stand-alone  determination  of 
the  level  of  repair  assignment  along  with  a brief  accessment  of  the  testa- 
bility of  the  UUT  that  should  be  required. 


2.3  REFERENCE  DOCUMENTS 

The  following  documents  were  utilized  as  reference  material  - pertinent  to 
this  section. 


Military; 

MlL-STD-1388  - Logistic  Support  Analysis 

MIL-STD-415D  - Test  Provisions  for  Electronic  Systems 

and  Associated  Equipment,  Design 
Criteria  for 


MIL-STD-1326 


NAV  MAT  INST 
3960.9 


Test  Points,  Test  Point  Selection  and 
Interface  Requirements  for  Equipments 
monitored  by  Shipboard  On-Line 
Automatic  Test  Equipment 

Built-In-Test  (BIT)  Design  Guide 
' Enclosure  III  dated  9 September  1978 
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Other  Publications: 


ARINC  Pub.  562-01-1-866  - 


Guide  to  the  Application 
of  Built-In-Test 


LEVEL  OF  REPAIR/TESTABILITY  CONCEPT 


A summary  checklist  of  the  major  Logistic  and  Testability  factors  that 
determine  the  UUT  Level  of  Repair  are  provided.  This  is  accomplished 
by  summarizing  the  Logistic  Support  Analysis  data  and  combining  this 
with  an  a c cessment  of  the  UUT's  testability. 


2.4.1  General 


For  the  purposes  of  this  discussion,  the  following  support  levels  are  defined 
along  with  their  generally  accepted  functional  goals  and/or  responsibilities: 

o Organizational  - On-board  test  to  isolate  a failure 

to  a single  faulty  Line  Replaceable  Unit  (LRU).  Remove 

and  replace  the  LRU  and  retest  system  to  verify  proper 
operation. 

o General/Intermediate  - Diagnostic  test  of  the  LRU  to 
isolate  to  a faulty  Shop  Replaceable  Unit  (SRU). 

Remove  and  replace  the  SRU  and  retest  the  LRU  to 
verify  proper  operation. 

o Depot  - Diagnostic  test  of  the  SRU  to  isolate  to  the 
faulty  component (s).  Remove  and  replace  components 
and  retest  the  SRU  to  verify  proper  operation. 


Concurrent  with  the  above,  other  support  requirements  that  directly  affect 
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and  influence  Maintainability  and  Reliability  characteristics  of  electronic 
design  and  are  major  inputs  to  the  LOR  are: 

o Number  of  sites  anticipated 

o Number  of  operating  hours  of  the  MISSION  VEHICLE 
o Number  of  MISSION  VEHICLES  to  be  activated 
o Skill  levels  required  at  each  echelon 
o Quality  and  avai  labi  lity  of  component  parts 

Decisions  based  upon  the  results  of  the  LOR  and  LSA  programs,  for  any 
given  piece  of  electronic  hardware,  directly  affect  the  maintenance 
concept,  spares  provisioning,  level  of  training,  depth  of  coverage  in 
technical  manuals  and  support  equipment  recommendations. 

Based  on  an  analysis  of  available  data,  it  was  determined  that  regardless 
of  the  care  taken  in  the  preparation  of  a detailed  Logistic  Support  Analysis 
(LSA),  a UUT  is  often  assigned  to  a support  level  which  is  either  incompat- 
ible, inefficient  or  totally  unnecessary. 

In  the  latter  part  of  this  section,  each  level  of  repair  is  discussed  in  detail 
as  it  applies  to  testing  of  electronic  equipment. 

2.5  RELIABILITY  AND  MAINTAINABILITY 

In  order  to  properly  assess  the  implications  of  this  guide  to  TPS  develop- 
ment, a cursory  description  of  Reliability  (R)  and  Maintainability  (M) 
practices  is  provided. 
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2.5.1  Reliobility  (R) 

Reliability  is  an  important  characteristic  of  military  electronic  equipment, 
and  all  factors  affecting  reliability  are  carefully  evaluated  in  trade-off 
analyses  beginning  in  the  early  design  phases  and  continuing  through  the 
manufacturing  phases.  Primary  requirements  should  be  set  to  assure  the 
achievement  of  the  required  reliability  levels,  for  any  specified  equip- 
ment^)/ in  the'mast  cost  effective  manner  ponible.  A Reliability  Program 
should  be  instituted  for  the  positive  control  of  parts  and  materials,  reli- 
ability test  and  evaluation,  and  the  analysis  and  correction  of  failures 
and  design  deficiencies. 

2.5.2  Maintainability  (M) 

The  prime  purpose  of  any  Maintainability  Program  is  to  describe  the 
management  controls  and  procedures  that  will  be  followed  by  the  contractor 
and  any  subcontractor  to  ensure  the  highest  possible  degree  of  maintain- 
ability,  consistent  with  operational  requirements  and  support  capabilities. 

The  major  task  of  influencing  design  regarding  M requirements  is  accom- 
plished by  the  establishment  of  a direct  line  of  communication  to  the 
cognizant  design  engineer.  The  M engineer  should  maintain  continuous 
design  liaison  so  that  an  analysis  of  the  various  design  alternatives  is 
conducted.  In  this  manner,  requirements,  accessments  and  guidance  can 
be  provided  in  areas  where  M is  affected. 

Because  of  the  interaction  and  trade-off  potentials  between  Reliability 
and  Maintainability,  close  coordination  between  the  two  functions  must 
exist.  The  Reliability  activities  provide  progressively  detailed  future 
prediction  rates  based  on  design  progress  and  baseline  changes.  This  data 
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will  be  used  by  Maintainability  for  determination  of  M parameters. 
Similarity,  Maintainability  will  keep  the  Reliability  group  informed  of 
all  significant  changes  in  quantitative  values,  based  on  these  M predic 
tions,  such  that  appropriate  trade-offs  and  corrective  actions  can  be 
initiated. 


A properly  constructed  M program  addresses  itself  additionally  to  factors 
other  than  inherent  design  reliability  and  configuration.  The  factors 
that  should  be  included  and  outlined  in  an  equipment  specification  are: 


o Interchangeability  requirements 


ftovisions  for  Built-In-Test  (BIT)  features, 
construction  and  packaging,  provisions  for 
test  points,  and  other  Maintainability 
parameters  as  specified  in  military  specifica 
tions. 


o Equipment  compatibility  with  anticipated 
Automatic  Test  Equipment. 


Built-In-Test  used  to  isolate  any  SRU  to 
within  a specified  confidence  factor  with 
a prescribed  Tum-Around-Time. 


2.6  MISSION  VEHICLE  AVAILABILITY 


Mission  essentiality  is  the  prime  requirement  in  any  military  scenario. 
Mission  essential  equipment  is  specified  for  the  various  types  of  Mission 
Vehicle  applications.  In  many  instances,  specific  missions  may  be 


I 
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conducted  with  limited  or  partially  working  systems.  However,  the 
ultimate-desirability  is  that  all  systems  be  operable.  Factors  influencing 
Mission  Vehicle  availability  are: 


o Reliability  of  the  system  or  its  sub-systems. 

o Maintainability  wherein  faulty  elements  or 
elements  of  a system  are  rapidly  Isolated  and 
replaced . 

o The  abi  lity  to  readi  ly  remove  and  replace  the 

faulty  element^)  of  a given  fault  isolation  group 
with  a functional  element  as  rapidly  as  possible, 

AND  Packaging  for  functional  modularity  plus 
appropriate  test  points  to  determine  the  size  of 
the  fault  isolation  group. 

o Logistic  Spares  available  at  the  appropriate 
maintenance  level,  and  that  any  movement 
between  maintenance  levels  be  conducted 
expeditiously. 

The  military  measure  of  determining  availability  of  a deployed  system 
is  expressed  as  Mean-Time-Between-Failure  (MTBF)  and  Mean -Time - 
To-Repa?r  (MTTR)  in  the  following  equation: 

MTBF 

Availability  = ■ — ' — 

MTBF  + MTTR 

MTBF  is  the  Mean  Time  Between  Failures 
MTTR  is  the- Mean  Time  To  Repair 


Although  there  is  a general  belief  that  each  of  these  factors,  (i.e.,  MTBF/ 
MTTR),-  are  definitive  in  theory,  they  are  not  as  clearly  defined  in  practice. 
Determining  exactly  when  an  equipment  has  failed  is  difficult  to  determine. 
This  is  particularly  true  where  today's  systems  have  been  reduntantly  designed 
or  have  the  capacity  to  operate  in  a degraded  mode. 

A brief  dissertation  on  how  MTBF  and  MTTR  affect  this  design  guide  follows: 

2.6.1  Mean  Time  Between  Failure  (MTBF) 

Micro-electronic  technology  has  advanced  wherein  the  cost,  weight  and 
power  of  a given  system  function  hos  declined,  systems  have  become  more 
and  more  complex.  Because  the  number  of  active  elements  for  a given  system 
has  increased  dramatically,  MTBF's  have  tended  to  become  lower,  even  with 
improvements  in  device  reliability. 

Various  techniques  including  redundancy  are  widely  used  to  improve  the 
situation.  Predicated  on  our  analysis,  one  must  accept  that  with  highly 
complex  systems,  the  effect  of  MTBF  on  availability  is  statistically  limiting 
and  that  improvements  to  MTTR,  as  outlined  below,  usually  provide  the  most 
cost  effective  solutions  to  availability  problems. 

2.6.2  Mean  Time  To  Repair  (MTTR) 

MTTR  is  a very  complex  function  and  to  develop  the  techniques  necessary  to 
improve  it,  the  effects  of  the  various  elements  must  be  identified  and  under- 
stood so  that  the  proper  life  cycle  cost  analysis  can  be  made  for  each  main- 
tehance  level,  MTTR  may  be  generally  described  as  follows: 


where  is  the  time  taken  to  detect  a malfunction 

of  the  electronic  unit. 

<2  *|  is  the  time  taken  to  isolate  a failure  to  a fault 
isolation  group. 

tgg  is  the  time  taken  to  remove  and  replace  the 
faulty  elements. 

t^  is  the  time  taken  to  confirm  that  the  repair  action 
was  successful . 

o tp  Time  Taken  to  Detect  Failure 

Essential  where  safety  or  mission  success  requires 
a need  to  know  rapidly  that  an  equipment  is 
malfunctioning.  This  element  then  may  be  the 
only  driving  factor. 

Equipments  of  this  type  still  have  to  be  maintained, 
and  it  should  not  be  allowed  that  the  primary  require- 
ment exclude  other  testability  requirements. 

o <2  t|  Time  Taken  to  Isolate  a Failure 


The  time  taken  to  isolate  to  a specific  fault  isolation 
group  is  a direct  function  of  the  testability  design  of 
the  UUT  or  the  extent  to  which  BIT  has  been  incorporated. 


T 


” 


° ^3  Vr  ^'me  ^a^en  to  Remove  and  Replace  Faulty 

Element 


Ideally,  a malfunction  will  result  in  the  identifica- 
tion of  a fault  isolation  group  of  a single  element 
of  a major  assembly.  Without  an  adequate  design 
for  testability,  this  may  not  occur.  It  can  be  readily 
appreciated  that  adequate  fault  isolation  will  reduce 
the  number  of  assemblies  to  be  spared,  and  the  time 
taken  to  replace  a single  element  will  be  less  than 
for  a group. 

The  major  requirement  is  that  the  equipment  should 
be  designed  for  ease  of  removal  and  replacement  of 
all  identifiable  (by  the  fault  isolation  group)  sub- 
assemblies. 

o K . t_  Time  Taken  to  Confirm  that  the  Maintenance 
4 C 

Action  was  Successful 


This  element  is  important  at  all  maintenance  levels, 
but  particularly  where  the  unit  under  test  has  been 
transferred  from  one  maintenance  level  to  another. 
It  is  not  unusual  for  test  tolerance,  and  certainly 
test  thoroughness,  to  be  less  at  the  organizational 
level  than  at  other  levels  of  maintenance,  particu- 
larly where  sub -assemblies  may  need  calibration  or 
adjustment. 
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2.6.3  Bui  It- In-Test  (BIT) 


Before  determining  how  to  evaluate  and/or  implement  BIT,  it  is  necessary 
to  determine  the  type  of  testability  that  is  necessary  and  readily  provided 
for  a particular  type  of  equipment  at  all  maintenance  levels.  Proper 
implementation  of  BIT  at  the  Organizational  (O)  level  is  just  as  dependent 
on  testability  as  are  test  techniques  using  ATE  or-  test  equipments  at  the 
general  support  and  depot  levels. 

Maintenance  testing  at  the  organizational  level  should  be  accomplished 
by  use  of  BIT  techniques  supplemented  where  necessary  by  contact  type 
testers  and  should  be  a goal  to  provide  maintenance  test  using  BIT  only. 

The  term  BIT  has  been  used  in  context  to  clarify  a group  of  techniques 
that  are  used  for  testing  equipments  at  the  organizational  level.  In 
developing  checklists  for  testability,  these  techniques  will  be  considered 
as  part  of  an  overall  testability  requirement. 

From  a cost  standpoint,  it  is  highly  desirable  that  the  fault  isolation 
group  is  a unity  which  requires  a minimum  quantity  of  spares.  However, 
if  the  time  taken  to  isolate  to  a small  ambiguity  group  is  excessive  or 
the  additional  BIT  hardware  overhead  exceeds  an  economic  or  reliability 
level,  it  may  be  appropriate  to  accept  a higher  fault  isolation  group. 

In  the  past,  a major  objection  to  the  incorporation  of  adequate  BIT 
hardware  was  cost,  both  in  terms  of  additional  design  cost  and  recurring 
item  cost.  Recent  studies  have  shown  that  the  cost  of  adding  BIT 
techniques  has  been  relatively  modest  in  comparison  to  the  life  cycle 
sparing  and  maintenance  cost  saving,  as  identified  below: 
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2.6.4  ’BIT1  Quality 


If  MTTR  = K]  *D  + K2  *]  + K3  *rr  + K4  fc'  fhen  the  *-«stabfllty  at  organi- 
zational level  could  be  described  as  Kj  t^  + Kj  tj  = BIT  Quality. 

Kj  is  a complex  factor  which  is  a function  of  the  Military  Essentiality 
Code  MIL-STD  1388-2,  the  type  of  equipment  qnd  the  type  of  technology 
employed.  Presently,  BIT  is  often  driven  purely  by  the  Military  Essential- 
ity Code.  For  instance,  in  an  aircraft  the  primary  driver  for  BIT  will  be 
the  fact  that  flight  safety  has  to  be  maintained  and  a malfunction  of  an 
equipment  essential  to  personnel  safety  has  to  be  quickly  recognized. 
Whereas,  in  many  cases,  equipment  failure  may  only  partially  impair 
the  ability  of  a weapon  system  to  function,  for  instance,  a defective 
channel  in  a multi-channel  communication  system. 

The  benefits  expected  to  be  realized  by  the  addition  of  BIT  are: 

o Reduced  maintenance  skill  levels 

o Reduced  maintenance  man-hours 

o Reduced  MTTR 

o Improved  availability 

o Reduced  level  of  O-level  test  equipment 

o Reduced  maintenance  life  cycle  cost 

Penalties  that  might  be  expected  are: 

o Increase  in  acquisition  cost 


o Decrease  in  MTBF 


o Increase  In  weight/  power  requirement  and  heat  dissipation 
o increase  in  sub-assembly  spares  at  organizational  level 
o Increase  in  canibalization  at  organizational  level 

Depending  on  the  type  of  equipment  and  its  intended  environment,  all  of 
the  above  factors  have  to  be  taken  into  account. 

BIT  should  be  looked  upon  as  a primary  part  of  testability.  The  extent  to 
which  BIT  is  implemented  must  be  determined  by  the  cost  of  Incorporation 
compared  to  the  improved  availability  and  the  reduction  of  life  cycle 
maintenance  costs.  If  equipment  is  designed  to  be  testable,  the  cost  of 
BIT  and  maintenance  will  be  reduced. 

2.6.5  Person  nel/Monogement 

The  technical  skills  required  to  accomplish  electronic  system  maintenance 
are  defined  in  the  following  manuals: 

AR61 1-1-1  - Manual  of  Commissioned  Officer 

Military  Occupational  Specialties 

AR611-112  - Manual  of  Warrant  Officer 

Military  Occupational  Specialties 

AR61 1-201  - Enlisted  Military  Occupational  Specialties 

The  classifications  and  specialties  defined  therein  provide  for  adequate 
skill  level  definition  and  commensurate  qualifications  and  initial  training. 


I 
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Some  areas  of  personnel  and  shop  management  that  should  be  considered 
are: 

2.6.6  Training 

Specialized  training  is  required  to  effect  total  system  definitization.  An 
operation  of  this  type  requires  that  the  test  operator  not  only  be  familiar 
with  mature  functional  test  setup,  but  provides  him  with  the  capability  to 
analyze  a faulty  test  setup. 

Lack  of  this  type  of  training  diminishes  the  value  of  test  programming  by 
extending  the  test  time  and  too  frequently  rely  on  a random  method  to 
affect  a repair. 

Random  substitution  causes  good  units  to  erroneously  enter  the  repair  cycle 
and  expends  spares  inventory  at  an  excessive  rate,  thereby  increasing 
spares  requirements. 

General  and  Depot  support  levels  should  employ  either  continuous  or  frequent 
training  courses  to  provide  and  maintain  highly  skilled  troubleshooting 
technicians. 

2.6.7  Cannibalization 


A major  identifiable  problem  with  support  below  the  Organizational  level  is 
the  cannibalization  of  one  unit  to  repair  another. 

Most  test  programs,  particularly  those  developed  for  use  on  Automatic  Test 
Equipment,  are  written  to  detect  b single  failure.  If  the  test  unit  comes  to 
the  General  Support,  Depot  or  Vendor  with  multiple  failures  induced  by 
substitution  through  cannibalization,  the  test  time  required  to  affect  repair 
is  significantly  increased. 
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Cannibalization  is  generally  not  "allowed,  " therefore,  no  records  of  the 
substitution  activity  or  any  description  of  the  failure  symptoms  can  be 
quantified. 

An  instance  might  be,  at  the  Organizational  level,  the  crew  of  an  opera- 
tional Weapon  system  will  do  all  in  its  power  to  achieve  a high  percentage 
of  mission  availability.  This  includes  cannibalization  and  other  normally 
authorized  work-arounds  which  contribute  to  problems  at  the  other  support 
levels  including: 

o Cannibalization  - resulting  in  multiple  unit  failures 
and  configuration  anomalies. 

o Unauthorized  repairs  - resulting  in  damaged  hardware 
and  configuration  anomalies. 

o Improper  failure  reporting  - resulting  in  additional  test 
time  to  identify  failures. 

These  problems  can  be  controlled  by  sound  management  at  the  organiza- 
tional level  through  training,  quality  assurance  provisions  and  incentives 
for  following  the  rules. 

2.6.8  Spares 

The  LSA  identified  system  requirements  by  maintenance  level  and  fre- 
quency of  use,  for  spares,  repair  parts,  and  consumables.  Impacts  upon 
storage  spaces,  supply  facilities,  equipment,  personnel,  and  procedures 
are  evaluated  for  each  support  system  approach  under  consideration. 

Supply  data  resulting  from  the  LSA  include  spares  and  repair  parts  provi- 
sioning; consumption  and  usage  rates;  recommended  allow  cnees;  supply 
storage  requirements;  and  Source,  Maintenance  and  Recoverability  coding. 
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Th  ; military  spares  provisioning  system  is  complex  and  costly  to  establish 
and  maintain  and  is  very  susceptible  to  problems  if  improper  maintenance 
activities  are  practiced.  (Re:  NASC;  NAFI  documentation) 

There  exists,  therefore,  a proper  management  of  spares  inventory  in  support 
of  the  automatic  test  and  repair  activity  that  becomes  a major  factor  contri- 
buting to  a maintenance  program's  success. 

2.7  TEST  TOLERANCE 

The  preceding  sections  have  delved  into  the  philosophy  of  TPS  testing, 
however,  the  main  driving  factor  is  testability  and  test  tolerances  as 
discussed  below: 

o It  is  imperative  that  test  tolerances  are  organized  so 
that  test  requirement  definitions  are  correlative  at  the 
different  support  levels. 

o Figure  2-1  illustrates  a classical  tolerance  cone  that 
defines  the  test  tolerance  build-up  from  basic  design 
tolerance  through  the  various  support  levels  to  the 
operating  environment. 

o The  test  tolerance  element  becomes  most  critical  at 
the  General  Support  and  Depot  Maintenance  levels 
where  very  complex  systems  using  ATE  may  attribute 
to  long  test  times.  Exemplary  design  for  testability 
and  BIT  hardware  can  be  used  to  reduce  the  Mean 
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Time  to  Repair  (MTTR)  at  these  support  levels 
and  consequently  reduce  the  quantity  of  spares 
and  ATE  required  at  the  test  site. 

2.8  IDENTIFIABLE  LEVELS  OF  REPAIR 

2.8.1  Organizational 

This  level  is  responsible  for  maximum  mission  availability  of  a given 
electronic  suite  with  a minimum  of  time  consuming  diagnosis. 

The  generally  accepted  maintenance  ‘activity  specified  at  this  level 
is  the  replacement  of  a single  Line  Replaceable  Unit  (LRU)  diagnosed 
as  faulty  either  through  on-board-system-readi ness  tests,  Built-In-Test 
Equipment  (BITE)  or  by  contact  type  testers. 

This  level  has  been  grossly  neglected  and  offers  many  areas  for  improve- 
ment in  mission  availability  depending  upon  test  access  and  mission 
scenario. 

2. 8. 1.1  On -Board -Pi  agnosti  c-Test 

These  tests  are  normally  designed  to  verify  operational  readiness  by 
exercising  the  critical  system  functional  parameters  either  through 
the  Built-In-Test-Equipment  (BITE)  or  a software  program  exercised 
through  a central  computer  or  a combination  of  both. 
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Failure  indications  may  be  displayed  on  individual  LRU  BITE  indicators 
or  on  a visual  display/  printer  or  storage  medium,  i.e.,  magnetic  tape, 
tied  to  the  central  computer  diagnostic  program. 

A detailed  review  of  the  on  -board  -di  agnosti  c-test  capability  will 
invariably  result  in  the  conslusion  that  improvements  can  be  made  in 
both  diagnostic  isolation  and  failure  message  reporting. 

Diagnostic  isolation  can  typically  be  improved  to  reduce  failure 
ambiguities  and  to  extend  the  diagnostic  isolation  on  critical  para- 
meters to  a lower  level  of  replacement.  Reducing  failure  ambiguities 
means  that  only  the  faulty  unit  must  be'removed  and  replaced,  and 
the  good  unit  is  not  jeopardized  by  unnecessary  removal,  handling  and 
replacement.  This  procedure  also  allows  for  a minimum  spares  inventory. 

Extending  the  diagnostic  isolation  capability  allows  for  the  repair  of 
the  faulty  unit  at  the  organizational  unit  by  replacing  faulty  sub- 
assemblies.  This  decreases  higher  level  unit  spare  inventory  and  reduces 
unit  testing  at  the  next  maintenance  level. 

Failure  message  reporting  Is  a valuable  asset  and  can  typically  be 
expanded  to  include  troubleshooting  information  that  will  assist  in  pin- 
pointing an  otherwise  ambiguous  failure.  The  result  is  much  the  same 
as  improving  the  actual  diagnostic  software  and  results  in  fewer  spares 
and  less  handling  of  functional  units,  thereby  reducing  costs. 
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2. 8. 1.2  Contoct  Test  Equipment 


In  the  event  operational  readiness  cannot  be  verified  through  the  on- 
board-system-readiness test,  portable  contact  type  test  equipment  is 
required  to  complete  the  readiness  verification.  This  contact  type 
equipment  can  range  from  a simple  oscilloscope,  signal  generator  or 
meter  to  a complex  piece  of  special  purpose  diqgnostic  test  equipment. 


The  decision  to  use  this  equipment  or  specify  new  equipments  to  augment 
the  operational  readiness  test  depends  on  several  factors. 

o Operational  safety  or  mission  criticality  (Primary) 

o Reliability  (Secondary) 

o Contact  Equipment  Diagnostic  Capability  (Secondary) 


o Contact  Equipment  Test  Time  (Secondary) 

The  trade-offs  required  to  determine  whether  contact  test  equipment 
should  be  used  in  lieu  of  test  at  the  General  Support  level  have  been 
outlined  in  the  checklist. 


2, 8. 1.3  Performance  Monitor/Test 


Idealistically,  all  electronic  systems  would  employ  an  operational 
performance  monitoring  system  which  would  provide  the  operator  with 
an  evaluation  of  the  system  performance  or  any  malfunction  during 
the  operating  minion. 


e 
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Since  the  services  have  procured,  at  great  expense,  a multitude  of  test 
systems,  it  is  very  probable  that  an  existing  Performance  Monitor/Test 
system  can  be  improved  or  modified  that  will  provide  sufficient  informa- 
tion to  allow  for  repair  at  the  organizational  level.  This  precludes  the 
need  far  an  additional  test  at  the  General  Support  level . 

Fat  lure  Report!  ng 

Organizational  level  tests  are  only  valuable  if  they  display  and/or 
record  the  evaluation  data  In  proper  form.  Wherever  possible,  trouble- 
shooting information  should  be  included  with  the  failure  message.  This, 
of  course,  is  not  possible  when  the  BITE  flag  is  the  only  indication  of 
failure.  However,  when  BITE  is  controlled  by  a central  computer.  It  is 
quite  possible  that  additional  diagnostic  data  can  be  made  available  for 
display  or  recording  that  would  greatly  assist  the  technician  in  isolating 
the  failure. 

A detailed  review  of  the  operational  readiness  software  should  be  made 
to  determine  cost  effective  improvements  In  failure  message  reporting. 

Organizational  Support  Summary 

Those  major  factors  which  affect  Test  Program  Set  Design  have  been 
presented  in  narrative  to  assist  in  the  general  decision  making  process 
to  determine  the  need,  cost  effectiveness  and  technical  requirements 
for  Test  Program  Sets  at  the  Organizational  Support  Level. 

The  checklist  in  Figure  2.2  will  address  those  organizational  support 
level  questions  affecting  test  program  set  development. 
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2.8.2  General  Support  Level 


The  first  support  level  where  off-line  test  and  repair  of  faulty  electronics 
is  conducted  - the  shop  is  typically,  but  not  necessarily,  located 
at  an  operational  facility  and  provides  "batch -test-processing" of  elec- 
tronic units  identified  as  faulty  at  the  Organizational  Level  (i .e., 
replacement  of  a faulty  LRU  by  BIT/BITE  analysis). 

The  General  Support  facility  normally  provides  test  and  repair  facilities 
for  Line  Replaceable  Units  (LRU's)  involving  removal  and  replacement  of 
Shop  Replaceable  Units  (SRU's)  and  LRU  retest  and  return  to  Organizational 
Level  for  spares  stock. 

Due  to  the  normal  proximity  of  the  General  Support  to  the  Organizational 
Level,  it  is  common  to  depend  on  very  short  term  turnaround  repairs  of 
faulty  units.  Normalized  general  support  and  organizational  supply 
facilities  are  located  at  the  same  site. 

Any  trade-off  that  can  reduce  test  complexity  and  test  time  that  can  be 
effectively  accomplished  at  the  Organizational  Level  should  be  done  there. 
Effective  on-board-diagnostic-isolation  testing  will  save  countless  hours 
and  dollars  at  the  General  Support  Level. 

It  is  not  uncommon  for  the  General  Support  Level  to  provide  Shop  Replace- 
able Assembly  (SRU)  repair  service.  This  makes  the  on-board  performance 
test  even  more  critical  since  SRU  testing  is  much  simpler  and  faster  than 
LRU  testing  and  would  merely  require  a functional  retest  of  the  LRU  after 
SRU  repair. 
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Because  of  the  diverse  test  requirements  of  this  support  level,  the  test 
equipment,  adapters  and  software  programs  are  quite  numerous,  costly 
and  complex.  Anything  that  can  be  done  to  effectively  reduce  the 
quantity  and  complexity  at  the  General  Support  Level  efforts  should  be 
considered. 

The  decision  whether  to  repair  a faulty  unit  at  the  General  Support  Level 
is  discussed  in  this  section. 

2.8. 2.1  Test  Equipment 

The  General  Support  facility  should  contain  a large  variety  of  test  equip- 
ment ranging  from  simple  manual  instruments  through  complex  peculiar  and 
general  purpose  automatic  test  systems. 

Maximum  use  should  be  made  of  the  general  purpose  ATE  to  minimize 
manual  operations  and  allow  for  consistency  in  test  program  format  and 
test  language. 

2.8. 2. 2 LRU/SRU  Test 

Most  modem  electronic  system  LRU's  can  and  should  be  tested  using  a 
General  Purpose  Automatic  Test  System.  The  present  exceptions  to  this 
are  some  RF  systems  either  requiring  extreme  frequency  and/or  power 
stimulus/measurement  or  extremely  high  speed  digital  systems  requiring 
dynamic  test.  Other  exceptions  are  those  LRU's  that  have  very  limited 
test  access  or  ATE  incompatibilities. 

These  exceptions  are  typically  supported  by  Peculiar  Ground  Support 
Equipment  (PGSE)  furnished  at  the  organic  support  facility  by  the 
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electronic  supplier  or  returned  to  the  suppliers  facility  for  repair  or 
replacement. 

LRU  diagnostic  test  programs  are  costly  and  complex  to  develop  and 
maintain.  Every  means  to  minimize  the  complexity  and  maximize  the 
test  effectiveness  must  be  considered. 

The  questions  to  consider  in  determining  LRU  test  at  the  General  Support 
level  are  contained  in  the  checklist  Figure  2.2. 


The  decision  of  WHERE,  WHEN,  HOW  and/or  IF  to  test  and  repair  a 
SRA  involves  a myriad  of  complex  trade-off  factors.  One  might  be  that 
it  is  neither  economically  feasible  or  necessary  to  test  all  SRA's  in  an 
electronic  system.  When  the  decision  is  made  for  test  and  repair,  that 
responsibility  is  typically  assigned  to  the  Depot  level  or  the  SRA  is 
returned  to  the  electronic  equipment  supplier  for  repair  or  replacement. 
In  many  instances,  it  may  possibly  be  more  effective  to  repair  some 
SRA's  at  the  General  Support  Level  depending  on  the  Depot  work  load 
and/or  the  organizational  support  requirements. 


2. 8. 2. 3 Failure  Reporting 

Regardless  of  the  equipment  used  for  test  and  repair,  it  is  mandatory 
that  complete  and  accurate  descriptions  of  failures  be  recorded . Where 
UUT  failure  messages  contain  ambiguous  callouts,  it  is  required  that 
either  the  failures  be  prioritized  as  to  most  likely  or  that  troubleshooting 
information  be  provided  to  assist  the  technician  in  his  repair. 
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General  Support  Summary 

The  primary  responsibility  of  the  General  Support  Level  is  to  provide  rapid 
test  and  repair  of  LRU's  and  return  them  to  the  Organizational  Level  for 
use  as  spares. 

The  most  efficient  method  of  achieving  this  is  through  the  use  of  ATE. 

Also,  it  is  extremely  important  cannibalization  be  minimized  at  the 
Organizational  Level  in  order  to  effectively  accomplish  rapid  test  and 
repair  at  this  level.  Any  cannibalization  must  be  reported  in  detail  in 
order  that  real  failures  are  enumerated  to  provide  accurate  maintenance 
records. 

2.8.3  Depot  Level 

Depot  Level  is  the  last  opportunity  to  effect  a test  and  repair  of  elec- 
tronic equipment.  For  the  purpose  of  this  discussion,  consider  the 
electronic  equipment  supplier  as  an  extension  of  the  military  depot. 

This  premise  is  made  because  the  supplier  may  be  the  only  source  of 
proprietary  components  and/or  may  possess  the  only  and/or  most 
efficient  means  of  test  and  repair. 

The  major  problem  with  Depot  or  Supplier  support  is  the  time  required 
to  effect  a repair.  This,  of  course,  dictates  that  the  spare  inventory  at 
both  the  General  Support  end  Organizational  levels  be  adequate  to 
allow  for  Depot  replacement  in  order  to  achieve  a reasonable  operational 
mission  availability. 

9 

It  is  extremely  important  that  the  diagnostic  testing  done  at  the  General 
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and  Organizational  levels  results  in  accurate  failure  isolation  so  that 
"good"  units  are  not  cycled  through  the  Depot  pipeline. 


Depot  activities  typically  include  the  test  and  repair  of  LRU  chassis  back- 
planes or  wiring,  SRU's  on  ATE  and  LRU's  and  SRU's  requiring  Peculiar 
Ground  Support  Equipment  (PGSE). 


The  factors  to  consider  in  making  the  decision  if  and  where  to  test  and 
repair  are  outlined  in  the  checklist  Figure  2.2. 


2.8 .3.1  ATE 


At  the  General  Support  level,  ATE  should  be  used  for  test  and  repair  as 
much  as  possible  to  minimize  test  time  and  maximize  test  program  compati- 
bilities. 


Ideally,  the  same  ATE  will  be  available  at  both  the  General  Support  and 
Depot  levels  so  that  the  test  strategies  will  be  direcily  complimentary  and 
in  the  same  test  language. 


2.8  .3.2  Peculiar  Ground  Su 


uipment  (PGSE) 


When  PGSE  is  required  due  to  special  test  requirements,  it  is  highly 
desirable  that  the  test  language  be  as  similar  to  the  general  purpose  ATE 
language  as  possible.  This  allows  for  minimal  special  training  of  test 
personnel  and  provides  a thread  of  continuity  in  the  TPS  format. 


2. 8. 3. 3 LRU/SRU  Test 


The  majority  of  test  activity  at  Depot  should  be  SRU  test  and  repair. 
However,  some  LRU  test  and  repair  will  undoubtedly  be  required,  either 
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due  to  General  Support  level  work  load  or,  that  LRU  test  programs  do  not 
test  LRU  chassis  or  backplane  wiring. 

In  the  case  of  General  Support  level  overload,  it  is  recommended  that  any 
LRU  test  be  done  at  Depot  on  the  same  ATE  as  at  General  Support . In  the 
case  of  LRU  chassis  test,  it  is  suggested  that  cm  automatic  continuity  tester 
such  as  DITMCO,  FACT  or  DIGITRACE  be  used  and  not  done  on  ATE. 

2. 8.3.4  Vendor  Support 

Test  and  repair  at  the  vendors  facility  of  some  UUT's  will  always  be  required, 
pdrticularly  for  those  SRA's  that  have  d high  MTBF  but  at  a cost  that  prohibits 
a throw-away  classification. 

When  possible,  vendor  support  requirements  should  be  specifically  defined 
to  specify  a maximum  turnaround  time  so  that  the  General  Support  level 
spares  requirements  can  accurately  be  determined. 

It  is  not  technically  required  that  the  vendor  support  his  repair  activity  with 
ATE,  but  it  is  desirable  from  a cost  and  schedule  standpoint.  As  a minimum, 
the  vendor  test  must  be  compatible  with  the  military  depot  maintenance 
philosophy  to  assure  continuity  in  the  maintenance  support  chain. 

2.8  .3.5  Depot  Summary 

Time  is  the  essential  element  in  the  success  of  the  depot  support  level. 

Proper  utilization  of  a mix  of  manual,  automatic  and  peculiar  testers  such 
that  test  backlogs  are  minimized  is  extremely  important. 

Piece  part  spares  should  be  overstocked.  It  is  not  mission  effective  to  have 
a system  or  vehicle  unavailable  for  its  mission  for  lack  of  a ten -cent 
component.  11-27 


2.9  LEVEL  OF  REPAIR  CHECKLIST 


Level  of  Repair  studies  and  decisions  are  a subset  of  the  maintenance 
concept  plan,  which  itself  is  a part  of  Integrated  Logistic  Plan.  The 
maintenance  concept  determines  the  maintainability  in  design  require- 
ments to  be  imposed  on  the  hardware  engineers.  It  takes  into  account 
the  operational  requirements  of  the  weapon  systems  and  the  skill  levels 
required  at  each  level  of  maintenance.  The  level  of  repair  decisions 
a>e  used  by  the  logistic  support  planners  to  determine  spares,  training 
and  maintenance  facility  requirements. 

The  goal  of  a Level  of  Repair  Analysis  is  to  assure  required  operational 
availability  of  a system  considering  all  life  cycle  costs. 

The  purpose  of  this  checklist  is  to  assist  the  procuring  agency  in  deter- 
mining the  optimum  level  of  automatic  test  and  repair  support  for  military 
electronic  systems. 

This  checklist  assumes  that  some  sort  of  Logistic  Support  Analysis  (LSA), 
in  accordance  with  MIL-STD-1388-1/2,  has  been  accomplished. 

Use  of  the  checklist  will,  therefore,  either  confirm  the  results  of  the  LSA 
or  suggest  alternative  test  support  options. 

2.9.1  Support  Level 

Data  required  in  eoch  of  the  support  level  sections  is  available  from  the 
LSA  conducted  in  accordance  with  MIL-STD-1388.  If  no  LSA  was 
accomplished,  UUT  analysis  should  be  conducted  to  assure  that  the 
minimum  data  is  available. 
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Organizational 


Automatic  Test  defines  the  method,  if  any,  by  which 
a failure  is  detected  automatically  on-board. 

Contact  Test  Defines  the  method,  if  any,  by  which 
a failure  is  detected  through  the  use  of  portable, 
plug-in  type  equipment. 

Failure  Data  Reporting  should  be  in  a format  that 
when  a failure  is  reported  for  both  functional  arid  diag- 
nostic test,  it  provides  the  next  support  level  with  suffi- 
cient data  to  consistently  duplicate  the  indicated  failure. 

Diagnostic  Isolation  provides  for  a percentage  estimate 
of  all  testing  done  at  the  organizational  level.  For  an 
LRU  within  a subsystem,  "Does  the  automatic  and/or 
contact  test  equipment  isolate  to  a single  LRU  100% 
of  the  time?"  Or,  if  isolation  is  attempted  to  the  SRU 
level,  "What  percentage  of  SRU's  are  unambiguously 
detected  ? " 

The  quantity  of  available  spares  should  be  such  that 
those  failures  that  are  detected  at  the  organizational 
level  can  be  replaced  by  functional  units  from  stock. 

Cannibalization  should  be  strictly  prohibited. 
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General  Support 

The  level  of  repair  at  the  General  level  of  maintenance 
will  include  the  subsystem,  LRU,  SRU  or  actual  test 
equipment  maintenance  and  repair.  To  satisfy  the  non- 
ambiguity requirements  of  the  testability  specification, 
the  electronic  design  must  be  functionally  partitioned 
to  allow  for  a specified  degree  of  unambiguous  isolation. 
Failure  tolerances,  both  for  functional  failures  and 
degraded  performance  isolation,  will  be  somewhat  more 
stringent  than  that  at  the  Operational  level.  All  cases 
of  failure  at  the  operational  or  test  connector  interfaces 
shall  be  detectable.  It  shall  be  a general  requirement 
that  all  LRU's  be  capable  of  testing  at  the  General  Level 
of  maintenance  without  the  need  for  stimulation  by  another 
WRA  or  special  test  device. 

When  performing  LRU  fault  isolation,  the  minimum  accept- 
able requirement  for  non-ambiguous  SRU  isolation  is  as 
follows: 

1)  In  at  least  90%  of  the  cases  of  probable 
malfunction  of  an  SRU,  the  fault  shall  be 
isolated  to  a specific  SRU. 

2)  In  95%,  or  more,  of  the  cases  of  probable 
malfunctions  of  an  SRU,  the  fault  shall  be 
isolated  to  that  SRU  and  no  more  than  one 
other  SRU. 
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3)  In  all  cases  of  probable  malfunction  of 

an  SRU,  the  fault  shall  be  Isolated  to  that 
SRU  and  no  more  than  two  other  SRU's. 


To  demonstrate  the  acceptability  of  the  equipment  and  test 
program  to  satisfy  the  desired  non-ambiguity  requirements, 
a calculation  of  a figure-of-merit  (i.e.,  pass/fail  criteria) 
will  be  determined  in  accordance  with  the  formula 


FOM 


Failure  Messages 
Containing  (N)  or  less  SRU's 

Total  Failure  Messages 


X 100 


where  1 N 3 


A similar  formula  will  be  utilized  for  component  isolation  of 
a particular  SRU,  where  the  diagnostics  will  un -ambiguously 
fault  isolate  to 


1 ) 3 or  less  components  for  80%  of  the  possible 
faults,  and 

2)  5 or  less  components  for  90%  of  the  possible 
faults,  and 

3)  8 or  less  components  for  100%  of  the  possible 
faults. 

Failures  due  to  power,  clock  and  single  source  bussed  signals 
will  not  be  included  within  the  non-ambiguity  calculations. 

A thorough  analysis  of  the  test  program  is  required  to  establish 
the  expected  non-ambiguity  values  in  the  field  environment. 
The  method  of  calculation,  using  a diagnostic  message  count 
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os  the  criteria  for  the  FOM,  may  be  the  most  reasonable 
approach.  However,  the  results  can  be  effected  or 
biased  by: 


1)  Unnecessary  repetitious  and  redundant 
testing. 

2)  Non-comprehensive  functional  testing 
(i.e.,  missing  tests). 

3)  Combinational  and  iterative  testing  of 
logic  circuits  in  all  possible  bit  patterns. 


4)  Programming  structure  (i.e.,  independent 
tests  versus  combinational  tests  to  achieve 
same  results). 

5)  Intentional  or  unintentional  use  of  excessive 
probing  tests. 


The  full  intention  of  a figure-of-merit  is  to  provide  a level 
of  confidence  in  the  test  design  and  test  program  to  provide 
for  a high  degree  of  readiness. 


Spares  allocation  will  be  a function  of  the  maintainability 
analysis,  FMEA  and  the  percentage  of  real  isolation  messages 
attributed  to  the  particular  module.  Spares  availability  should 
be  such  that  the  MTTR  can  be  met.  A similar  spares  provision- 
ing, for  piece  part  components,  should  be  established  for  proper 
support  of  SRU  repair. 
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c)  Depot/Supplier 

Depending  on  the  weapon  system  to  be  supported,  the 
General  Level  of  Repair  may  be  adequate  to  resolve  most 
repair  problems.  However,  there  is  sufficient  complica- 
tion in  electronic  devices,  such  as  electro-mechanical 
and  electro-optical  devices  that  a special  Depot  level 
of  repair  may  be  warranted.  Such  devices  requiring 
stabilized  platforms,  antenna  tests,  RF  testing  and  the 
like  are  not  normally  repairable  at  the  General  Level. 

Special  calibration  procedures  and  equipment,  in 
conjunction  with  tailored  Automatic  Test  Equipment, 
would  be  required  to  duplicate  factory  test  and  repair 
procedures.  The  definition  of  these  special  test  require- 
ments must  be  specified  early  in  the  procurement  phase  and 
approved  by  the  procuring  activity. 

Automatic  and  special  test  equipment  must  rely  heavily  on 
comprshensive  self-test  features  in  order  to  minimize  the 
proliferation  of  added  test  equipment.  Every  attempt  should 
be  made  to  eliminate  the  need  for  calibration  standards  and 
special  alignment  fixtures. 

On  occasion,  it  may  be  necessary  to  return  the  unit  to  the 
manufacturer  for  single  unit  repair  and  adjustment.  However, 
it  should  be  the  policy  of  the  Army  that  a stand-alone  mainte- 
nance capability  be  resident  within  the  various  levels  of  repair 
with  minimum  dependency  upon  vendor  or  manufacturer  support. 


1 


1 


11-33 


This  self-contained  maintenance  capability  may  not  be 
obtainable,  however,  until  some  time  after  deployment. 

A specific  plan  for  phasing  out  the  vendor  must  be  an 
integral  part  of  the  support  plan  as  well  as  the  Configura- 
tion Control  Plan. 


FIGURE  2.2 


LEVEL  OF  REPAIR  CHECKLIST 


UUT  Nomenclature 

UUT  Cost  Planned  Service  Life 

* of  UUT's  per  Maintenance  Location 

Operational  Hours  per  Month 

Desired  Availability Estimated  MTBF 

Maintenance  Actions  per  Month  Scheduled 

Unscheduled 


Required  MTTR  ______________ 

Development  of  Test  Support  Cost  Recurring 

Non-recurring 

Repair  Cost  per  UUT  ____________  direct  spares  replacement 

depot  repair 
on-site  test  and  repair 
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SECTION  III 


3.0  THE  TPS  DESIGN  GUIDE 

3.1  GENERAL  DESCRIPTION 

The  TPS  Design  Guide  is  described  in  a general  sense  by  Figure  3.2. 
The  purpose  in  describing  the  guide  in  block  diagram  format  rather 
than  a stacked  "table  of  contents"  form  is: 

It  more  readily  demonstrates  the  "serial " flow  of  task 
elements  that  must  be  performed  to  develop  the  TPS. 

It  shows  the  time  sequencing  of  the  task  elements  and 
to  a great  degree  their  interrelationship.  In  essence, 
a sort  of  functional/time  PERT  chart  including  pacing 
items  and  looping  requirements. 

It  presents  the  ''total"  picture  of  task  elements  to  be 
considered,  understood  and  applied  in  the  development 
of  TPS's.  It  shows  where  to  start,  how  to  proceed, 
what  must  be  done,  and  when  to  perform  each  task 
element. 

The  TPS  development  effort  can  be  expressed  in  a very  simple  form. 
Figure  3.1  attempts  to  show  that  simplified  form,  but  there  are  a 
number  of  tasks  that  make  up  each  of  the  simplified  blocks.  These 
tasks  are  shown  In  Figure  3.2.  Because  of  the  many  tasks  that  are 
necessary  to  complete  the  development  effort,  the  simple  block  dia- 
gram is  shown  with  cross  references  to  the  detailed  block  diagram. 
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This  will  allow  the  guide  user  to  see  the  overall  development  effort  at  a 
glance  arid  the  detailed  steps  in  that  effort  if  desired. 

Figure  3.2  does  not  describe  the  results  of  functional  non-compliance  with 
the  task  elements,  or  the  effects  of  only  partial  compliance.  Some  of  the 
resultant  perturbations  are  self-evident,  and  the  text  of  the  guide  will 
define  to  the  guide  user  other  potential  detriments  to  the  engineering 
system  that  can  result  from  an  ill-accomplished  task  element. 

The  projected  purpose  of  Figure  3.2  in  its  presented  format  is  to  provide 
the  user  with  a visual  tool  that  not  only  describes  but  tracks  his  functions 
in  the  TPS  development  chain  regardless  of  the  size  of  his  portion  or  his 
requirements  of  applications. 

3.2  SYSTEM  FORMATTING 

Figure  3.2  sequentially  formats  the  engineering  system  presented  in  the 
guide.  Each  of  these  components  will  be  discussed  as  to' their  content  and 
place  in  the  total  picture  of  TPS's  development,  starting  with  the  Mission 
Vehicle  (be  it  an  electronic  system,  an  LRU,  an  SRU  or  an  SSRU),  and 
completing  with  the  parameters  of  TPS's  acceptance  by  the  paying  user. 

3.3  MISSION  VEHICLE 

♦ 

3.3.1  General 

The  initiation  of  any  type  TPS  development  task  generally  starts  at  a point 
this  guide  considers  "partway  down-the-line.  " In  order  to  organize  proper 
TPS  development,  the  management  and  engineering  systems  groups  perform- 
ing  their  assignments  must  be  provided  with,  and  exposed  to,  the  entire  real 
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and  potential  problem  matrices  that  can  be  demanded  by  the  Mission 
Vehicle  in  all  modes  of  its  operational  readiness  functions.  Therefore/ 
the  guide's  content  will  be  "started"  at  a "beginning"  point  that  farces 
the  required  Unit  Under  Test  (UUT)  understanding  capabilities. 

3.3.2  Unit  Under  Test  (UUT) 


The  UUT  in  the  guide  is  named  the  Mission  Vehicle  because  it  not  only 
performs  an  intended  task,  but  is  also  designed  to  accomplish  a MISSION 
of  some  type,  in  some  manner  and  to  some  degree. 

t 

This  UUT  can  be  a system,  a Line  Repairable  Unit  (LRU)  which  can  be 
part  of  a system;  a Shop  Repairable  Unit  (SRU)  which  is  part  of  an  LRU; 
or  a Sub-Shop  Repairable  Unit  (SSRU)  which  is  part  of  an  SRU.  The  first 
function  of  the  guide  is  to  systematically  provide  the  necessary  information 
for  understanding  the  UUT. 

i 

3.3.3  UUT  Definition 

The  UUT  is  first  defined  in  terms  of  what  type  of  component  it  is  from  an 
applications  standpoint,  both  functional  and  operational.  The  purpose  of 
the  UUT  definition  is  primarily  to  indoctrinate  management  and  engineering 
to  all  functional  and  operational  aspects  of  the  UUT,  to  blaze  a trail  to 
the  location  and  procurement  of  the  necessary  data  and  information  on  the 
UUT,  pnd  to  become  acquainted  with  the  personnel  and  organizations 
presently  and  potentially  to  be  involved.  In  addition,  the  guide  users 
are  Viow  prepared  to  understand  and  apply  the  UUT's  functions  of  perfor- 
mance, design,  support  and  configuration  control.  In  reality,  the  guide's 
first  checklist  of  user  evaluation  function  is  developing.  A complete 
checklist  covering  UUT  definition,  which  should  be  applicable  to  all 
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UUT's  after  considering  "what"  needed  additions  and/or  deletions  should 
be  made  as  a result  of  the  UUT's  own  peculiarities. 


3.3.4  UUT  Performance  Specification  (Component  Functions) 


The  UUT  performance  specification,  sometimes  called  the  production  speci- 
fication is  the  prime  definition  document  for  the  UUT.  It  is  normally  a 
standard  format  of  scope,  documents,  design  requirement  and  quality 
assurance  requirement.  The  content  of  this  specification  is  all  encompas- 
sing in  scope  except  for  certain  critical  elements  needed  primarily  to  support 
the  UUT  in  the  future.  This  specification  provides  for  design,  fabrication, 
inspection,  in-process  control,  in-process  testing,  functional  testing,  environ- 
mental testing  and  acceptance  testing  sometimes  including  the  "first  article 
acceptance  requirements.  " The  document  normally  requires  the  vendor 
prepare  an  Acceptance  Test  Procedure  and  the  necessary  test  facilities  and 
equipment  to  verify  to  the  customer  that  the  UUT  meets  its  production  speci- 
fication requirements.  Testing  is  normally  performed  on  PSTE  (Peculiar 
Special  Test  Equipment),  peculiar  to  the  vendor  and  as  a function  of  that 
vendor's  design,  fabrication  and  previous  testing  experience.  This  PSTE 
can  be  anything  from  a hot-mock-up  to  a sophisticated  testing  system, 
but  almost  always  it  is  still  peculiar  to  that  vendor.  Many  words  of  pro 
and  con  can  be  written  concerning  this  type  of  specialization  in  testing 
by  each  manufacturer  of  UUT's.  The  best  probably  would  be  that  at  least 
the  vendor  can  demonstrate  that  his  UUT  meets  the  production  specification, 
and  that  all  the  precise  elements  of  that  specification  have  been  met. 
Needless  to  say,  there  is  a proliferation  of  test  equipment  in  the  making 
(or  already  made)  but  to  date  the  economics  of  a continuing  UUT  supply 
source  seem  to  demand  a continuation  of  this  method  of  test. 
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SECTION  IV 


4.0  TEST  REQUIREMENTS/STRATEGY 

A major  factor  in  the  development  of  a test  program  is  the  generation  of 
test  requirement  and  test  strategy  information.  This  section  will  discuss 
the  steps  necessary  to  generate  this  information. 

The  items  to  be  discussed  in  this  section  include: 

1 . UUT  functional  requirements  and  the  critical  parameters 
that  must  be  determined  to  ensure  an  adequate  test. 

2.  The  test  approach  and  test  options  that  result  from  the 
functional  requirements  analysis. 

3.  The  isolation  ambiguities  and  their  effect  on  the  test 
approach . 

4.  Test  tolerances  and  their  relationship  to  the  maintenance 
concept  and  level  of  test. 

5.  Testability  and  its  importance  in  the  test  program  develop- 
ment process. 

6.  The  data  required  to  determine  the  test  requirements/ 
strategy,  and  the  data  required  to  document  the  results. 

4.1  UUT  FUNCTIONAL  REQUIREMENTS 

The  first  step  in  determining  the  test  requirements/strategy  is  to  determine 
if  a functional  test  is  necessary.  This  analysis  should  be  made  without  any 
consideration  being  given  to  the  test  equipment  to  be  used,  or  even  if  test 
equipment  exists  to  provide  a truly  functional  test.  This  analysis  should  be 
based  only  on  the  needs  of  the  unit  to  be  tested. 
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The  effective  way  to  arrive  at  this  decision  is  a somewhat  reverse  approach. 
That  is,  instead  of  asking  the  question,  "What  failures  will  be  found  by 
performing  a functional  test?"  - the  question  should  be  asked,  'What 
failures  will  NOT  be  found  by  performing  a non -functional  or  static  test?" 

This  decision  is  much  easier  to  arrive  at  in  SRU  testing  than  it  is  in  LRU 
testing.  For  example,  in  the  case  of  SRU  testing,  the  schematic  or  circuit 
diagram  can  be  reviewed  and  if  there  are  no  peculiar  timing  circuits, 
oscillators  or  clocks  embedded  in  the  SRU,  it  can  generally  be  assumed  that 
a static  test  will  provide  a test  sufficient  to  determine  the  operability  of  the 
SRU.  Of  course  there  are  always  exceptions,  one  of  which  is  where  the 
designer  advertently  or  inadvertently  designed  in  a race  condition  that  only 
appears  when  the  UUT  is  operating  at  speed,  but  these  conditions  are  rare, 
extremely  difficult  to  determine,  will  most  likely  be  found  in  some  other 
manner  such  as  design  proof  or  system  level  test,  and  will  usually  result  in 
a design  change.  There  is  also  the  case  where  a device  will  operate 
perfectly  normal  at  low  speed,  but  fails  to  function  properly  as  the  speed 
is  increased;  however,  this  type  of  failure  is  rare  enough  not  to  alter  the 
basic  approach. 

This  approach  is  also  valid  in  determining  whether  or  not  a functional  test 
is  required  at  the  LRU  level.  It  is  not  as  simple  a decision  to  arrive  at 
because  the  LRU  usually  consists  of  a number  of  SRU's  connected  together 
in  some  manner  not  easily  seen  by  a quick  review.  The  system  block 
diagram  is  generally  of  no  assistance  in  making  the  determination  because 
it  is  more  a question  of  the  types  of  elements  used  and  the  mechanizati  on 
of  those  elements  into  a system  that  decides  the  question.  For  example, 
were  static  or  dynamic  memory  devices  used ? Is  there  an  oscillator  or 
clock  internal  to  the  LRU,  and  if  so,  can  it  be  disabled  and  controlled 
from  an  external  source? 
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These  and  many  other  similar  types  of  questions  must  be  answered  before 
the  question  of  functional  or  static  testing  can  be  answered. 


Because  it  is  more  difficult  to  make  this  decision  at  the  LRU  level,  the 
optimum  method  would  be  to  involve  the  designer  of  the  LRU  in  the 
decision  making  process.  This  is  not  to  say  it  should  be  his  decision  in 
total,  because  most  designers  feel  that  the  only  adequate  test  would  be 
a full  functional  test.  This  is  not  true,  but  the  designer's  involvement 
is  desired  to  determine  the  critical  parameters  that  must  be  supplied  to 
the  UUT,  or  monitored  by  the  test  equipment. 

An  example  of  this  is  that  in  some  types  of  data  transmission  such  as 
Manchester  where  the  clock  to  reconstruct  the  bi  -phase  coded  data  is 
encoded  within  the  data,  rise  and  fall  times  can  be  a very  critical  para- 
meter. If  the  rise  and  fall  times  are  too  fast  or  too  slow,  it  can  result  in 
erroneous  data  being  received.  This  information  should  of  course  be 
contained  in  the  system  specification,  but  it  is  information  the  designer 
is  quite  aware  of  the  importance  of,  and  would  place  the  necessary 
emphasis  on  it.  On  the  other  hand,  there  may  be  a voltage  output  from 
the  LRU  that  comes  from  a regulated  source  and  at  a glance  would  appear 
to  require  a close  tolerance  measurement,  but  in  the  system  the  signal  is 
actually  used  only  to  indicate  the  presence  of  power.  The  only  measure- 
ment required  on  a signal  of  this  type  is  one  that  indicates  a voltage  of 
some  value  greater  than  that  necessary  to  overcome  the  threshold  of  the 
receiving  device.  This  again  is  information  the  designer  is  quite  aware 
of  and  by  including  this  information  in  the  test  requirements  will  prevent 
a close  tolerance  measurement  from  being  made  on  a signal  that  does  not 
require  It  which  could  cause  a failure  indication  when  the  LRU  is  in  fact 
operable. 
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4.2  TEST  APPROACH  AND  TEST  OPTIONS 


Once  the  UUT  functional  requirements  have  been  established,  it  is  then 
necessary  to  determine  the  test  approach  and  the  options  available  to  that 
approach . 

At  this  point,  it  is  necessary  to  give  some  consideration  to  the  capabilities 
of  the  test  equipment.  If,  for  example,  a functional  test  is  required,  but 
no  test  equipment  exists  or  can  be  procured  with  the  necessary  capabilities 
to  allow  this,  then  a part  of  the  test  approach  would  have  to  include  the 
design  of  a complex  interface  adapter  to  provide  the  storage,  buffering, 
unique  timing,  or  data  conversions  to  compensate  for  the  inadequacies  of 
the  test  equipment. 

It  should  be  pointed  out  in  this  instance  that  the  test  equipment  with  the 
capabilities  most  closely  approaching  the  functional  requirements  of  the 
UUT  is  not  necessarily  the  correct  choice.  Take  for  example  the  case 
where  the  data  has  to  be  inputted  to  the  UUT  at  a specific  frequency  of 
10  MHz,  and  the  choice  is  between  a tester  that  is  capable  of  providing 
data  at  5 MHz  and  one  with  a maximum  rate  of  100  KHz.  Consideration 
should  be  given  to  the  types  of  devices  required  to  ensure  reliable  capture 
of  the  data  at  the  higher  rate  versus  the  devices  required  at  the  lower  rate. 
The  resultant  noise  generated  by  the  faster  data  transfer  rate  should  also  be 
examined,  and  if  test  time  is  not  a major  factor,  the  tester  with  the  slower 
rate  should  be  given  serious  consideration.  Cost  would  certainly  enter  into 
the  decision  process  also,  as  the  tester  with  the  higher  data  transfer  rate 
would  in  all  probability  be  the  more  expensive  of  the  two. 

In  addition  to  determining  the  type  of  test  equipment  to  be  used,  the  test 
approach  should  also  include: 
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4.2.1  Configuration  Audit 
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Establishing  the  configuration  of  the  UUT  that  the  test  program  is  to  be 
written  for,  and  controlling  that  configuration  throughout  the  develop- 
ment cycle.  As  changes  to  the  UUT  take  place  during  the  test  program 
development  period,  they  should  be  reviewed  and  the  decision  made  as 
to  whether  they  should  be  incorporated  at  the  time  or  accumulated  and 
included  at  the  end  of  the  development  period.  Major  changes  should 
of  course  be  included  at  the  time,  but  minor  changes  to  the  test  unit 
that  do  not  grossly  effect  the  operation  of  the  item  can  cause  the  develop- 
ment time  to  increase  if  they  are  incorporated  as  they  occur.  They  should 
be  accumulated  and  included  at  the  conclusion  of  the  development. 

4.2.2  Computer  Aided  Program  Preparation  (GAPP) 

Determining  the  need  for  computer  aids  in  the  UUT  analysis  process  - the 
analog  analysis  aids  such  as  CAPS  and  ISPICE  can  be  of  some  use  in  simu- 
lating complex  circuits  and  providing  the  test  engineer  with  information 
on  the  expected  results  for  a given  set  of  conditions.  In  existing  computer 
aided  analog  circuit  design  programs,  whether  it  is  used  for  design  of 
analysis,  the  biggest  limiting  factor  is  the  lack  of  accurate  and  complete 
models  for  active  components  such  as  transistors,  op-amps,  comparators, 
regulators,  etc.  For  example,  it  is  difficult  if  not  impossible  to  include 
in  the  model  all  parameters  and  tolerances  of  an  op-amp  that  will  affect 
its  operation,  resulting  in  questionable  accuracies  of  the  analysis  results. 

Any  wlde-band  analog  components  just  compound  the  problem. 

Due  to  the  lack  of  good  models  for  active  components,  results  from  computer 
aided  analysis  generally  have  tolerances  and  uncertainties  that  are  not  suited 
for  general  simulation  of  complex  circuits,  followed  up  by  detailed  theoret- 
ical analysis. 
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Component  failure  mode  analysis  has  been  tried  by  using  ISPICE  with 
some  success.  However,  the  same  problem  with  active  component  model- 
ing was  experienced  in  this  application  also,  therefore,  the  same  limita- 
tion applies. 

The  problem  with  active  components  modeling  compounds  itself  when  wide- 
band circuits  such  as  RF  or  video  are  involved.  With  state-of-the-art 
circuits  designs  leaning  more  and  more  toward  digital,  the  solution  to  the 
modeling  problem  does  not  appear  to  be  forthcoming. 

Computer  aids  in  circuit  analysis,  with  its  inherent  faults,  can  still  be  cost 
effective,  particularly  in  large  programs  where  many  test  engineers  are 
doing  circuit  analysis.  As  with  any  tool,  its  usefulness  can  be  enhanced 
if  the  user  recognizes  its  shortcomings  and  applies  it  properly. 

Another  method  for  accomplishing  this  that  has  proven  effective  is  the  use 
of  bench  analysis.  If  the  unit  to  be  tested  is  available  during  the  analysis 
period,  some  very  useful  information  can  be  gained  by. performing  bench 
evaluations  to  determine  the  reactions  of  complex  circuits  during  certain 
failure  modes.  This  information  can  of  course  be  gained  from  a paper 
analysis,  but  the  bench  evaluation,  if  the  necessary  equipment  is  avail- 
able, is  faster  and  the  results  generally  more  accurate.  If  the  bench 
evaluation  is  used,  extreme  care  should  be  taken  to  ensure  that  no 
damage  occurs  to  the  UUT. 

The  bench  evaluation  method  is  most  effective  on  analog  circuits.  For 
digital  circuits,  it  would  be  of  little  value.  The  computer  aid  or  the 
paper  analysis  are  the  only  practical  methods  for  developing  digital  test 
patterns.  The  computer  aids  in  use  today  such  as  LASAR  are  commonly 
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called  Automatic  Test  Program  Generators  (ATPG).  Although  they  share 
this  common  name,  there  are  differences  in  the  way  they  operate.  As  a 
result  of  this,  a part  of  the  test  approach  is  not  only  to  decide  if  ATPG 
is  to  be  used,  but  also  the  type  of  ATPG  to  be  used.  There  are  two 
general  categories  of  ATPG  even  though  their  operation  within  these 
categories  may  differ.  The  two  categories  are: 

o Fault  Dictionary 

o Guided  Probe 

The  basic  differences  between  the  two  is  that  the  fault  dictionary  type 
applies  patterns,  accepts  responses,  and  after  evaluation  of  the  responses 
outputs  a list  of  "most  probable  faults."  From  this  list  the  faulty  component 
is  identified.  The  guided  probe  type  of  ATPG  applies  input  patterns, 
accepts  responses,  and  if  an  incorrect  response  is  received,  the  operator 
is  given  a message  to  connect  a probe  to  some  point  in  the  circuit,  and 
the  response  patterns  are  once  again  evaluated.  This  is  repeated  until  the 
faulty  component  is  identified. 

Both  types  of  ATPG  are  effective  in  the  identification  of  failed  components, 
and  the  decision  on  which  one  is  the  correct  one  for  a given  task  has  to  be 
based  on  things  such  as: 

o The  type  of  tester  used.  Some  manufacturers  supply  ATPG 
that  only  runs  on  their  systems,  so  if  another  type  is  to  be 
used,  a translator  is  required  to  allow  it  to  run  on  any 
other  test  set. 

o The  amount  of  simulation  time  available.  The  fault 
dictionary  type  of  ATPG  generally  requires  longer 
simulation  run  time  than  the  guided  probe  type. 
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o Accessibility  to  the  UUT.  If  the  guided  probe  type  is 
used,  the  test  operator  must  have  access  to  the  points 
specified  by  the  probe  messages. 

o Level  of  isolation  required.  The  fault  dictionary  type 
of  simulator  generally  provides  a number  of  "possible 
faults,  " where  the  guided  probe  type  will  in  most 
cases  isolate  to  the  failed  component. 

It  should  be  noted  that  it  is  not  always  cost  effective  to  use  any  type  of 
ATPG.  On  simple  digital  SRU's,  the  modeling  time,  computer  time  and 
other  associated  cost  cannot  be  justified,  and  manual  pattern  generation 
is  the  correct  thing  to  do.  This  decision  should  be  made  during  the  initial 
circuit  evaluation. 


4.2.3  Test  Level 


Another  important  decision  to  be  made  is  whether  or  not  an  end-to-end 
test  is  sufficient.  If  it  is  determined  that  diagnostic  fault  isolation  is 
required,  the  level  of  isolation  must  also  be  decided.  This  decision  is 
one  of  the  largest  contributors  to  the  cost  of  a test  program  set  and  cannot 
be  treated  lightly.  The  development  of  a test  program  becomes  more 
difficult  as  the  component  groups  become  smaller.  If  an  end-to-end  test 
is  all  that  is  required  to  support  the  required  operational  readiness  level, 
then  the  development  process  should  end  at  that  point.  If,  however, 
fault  isolation  is  required,  the  development  is  extended  by  an  amount  of 
time  proportional  to  the  isolation  level  required.  Unfortunately,  this  is 
not  a linear  time  extension.  The  optimum  isolation  level  would  of  course 
be  down  to  a single  component  100%  of  the  time.  Even  if  this  were  possible, 
which  it  is  not,  the  test  program  development  time  and  the  associated  costs 
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would  be  beyond  reason.  At  the  other  end  of  the  scale  is  the  simple 
functional-  end-to-end  test.  There  is  a point  in  between  these  two 
extremes  that  is  the  correct  level  for  each  support  activity.  The 
selection  of  this  point  is  very  important  and  should  be  based  on 
factors  such  as: 

o Types  of  spares  available  at  a maintenance  site. 

o Quantity  of  spares  available  at  a maintenance 
site. 

o Rework  capability  at  a maintenance  site. 

o Reliability  of  the  unit  to  be  tested. 

o Built-In-Test  (BIT)  and/or  Built-In-Test  Equip- 
ment (BITE)  in  the  unit  to  be  tested. 

o Accessibility  of  the  unit  to  be  tested. 

o Testability  of  the  unit  to  be  tested. 

o Complexity  of  the  unit  to  be  tested. 


Having  evaluated  the  above  items,  it  should  then  be  possible  to 
determine  if  diagnostic  fault  isolation  is  required,  and  if  so,  what 
that  level  of  isolation  should  be. 
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4.3  ISOLATION  AMBIGUITIES 


Isolation  ambiguities  can  have  an  effect  on  many  phases  of  the  test  program 
development  cycle,  the  support  of  that  program  and  the  hardware  the  pro- 
gram was  designed  to  support. 

With  ambiguity  being  defined  as  "capable  of  being  understood  in  two  or  more 
possible  senses,  " and  isolate  defined  as  "to  select  from  among  others,  " then 
a loose  definition  of  isolation  ambiguity  would  be  "to  select  from  among 
others  in  two  or  more  possible  senses.  " This  is  where  the  problem  begins. 

With  a definition  as  stated  above,  it  is  not  difficult  to  understand  why  no 
clear  measurement  of  isolation  ambiguity  has  ever  been  defined.  It  also 
becomes  easy  to  understand  that  having  an  ambiguous  statement  with  no  way 
to  measure  the  results,  problems  can  be  created. 

Isolation  ambiguity,  however,  has  long  been  the  accepted  method  of 
measuring  test  program  quality,  but  it  is  in  fact  more  a measure  of  the 
testability  of  the  device  being  tested.  The  test  program  cannot  improve 
on  the  testability  of  any  piece  of  hardware.  If  access  to  the  internal 
circuit  elements  was  not  made  available  through  the  use  of  things  such  as 
test  points,  partitioning  into  functional  groups  and  mechanical  packaging, 
the  isolation  ambiguity  will  be  increased. 

This  fact  must  also  be  considered  in  determining  the  test  approach.  If  the 
mission  support  level  requires  diagnostic  fault  isolation  to  small  component 
groups,  but  the  unit  was  not  designed  with  the  necessary  visibility  to  allow 
this,  the  test  program  development  becomes  very  complex.  In  this  situation, 
manual  probing  is  the  only  way  to  reach  the  desired  ambiguity  level. 
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When  monual  probing  is  required,  not  only  is  the  development  complicated 
by  having  to  specify  the  probe  points  and  route  those  signals  into  the  test 
set,  but  once  the  program  is  released  for  use,  the  unreliability  of  probes 
that  must  remain  connected  to  UUT's  throughout  the  program  run  time  can 
be  a major  source  of  problems.  This  is  especially  true  in  the  case  of 
conformally  coated  boards. 

The  only  true  solution  to  this  is  designing  the  electronics  for  better  test- 
ability, but  there  is  existing  equipment  that  must  be  tested  and  until  the 
design  engineers  become  more  aware  of  this  need  and  learn  the  techniques 
necessary  to  implement  it,  the  problem  will  be  with  us  and  must  be  con- 
sidered in  determining  the  test  approach. 

4.4  TEST  TOLERANCES 

One  very  important  item  that  can  have  an  effect  on  both  the  time  to 
develop  and  the  quality  of  a test  program  is  the  test  tolerance.  There  are, 
of  course,  tolerances  that  must  be  established  to  ensure  that  the  unit  will 
perform  its  intended  function  as  a part  of  a weapons  system.  These  tolerances, 
however,  are  not  necessarily  the  ones  that  should  be  used  for  test. 


The  test  tolerance  must  be  established  to  provide  some  guarantee  that  the 
unit  will  operate  properly  in  the  next  higher  assembly.  The  method  used 
to  accomplish  this  is  a tighting  of  the  tolerances  the  lower  the  level  of  test. 
This  is  called  a Tolerance  Cone,  The  tolerance  cone  as  shown  in  Figure  2*1 
shows  the  nominal  design  value  and  the  build-up  of  tolerances  as  the  level  of 
test  changes.  For  example,  the  depot  level  of  test  shows  a wider  tolerance 
than  the  factory  level . At  the  faetory  level,  the  components  used  in  the 
assembly  are  for  the  most  part  much  closer  to  their  design  value. 
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This  allows  for  tighter  measurements  to  be  taken,  and  these  tighter  measure- 
ments should  be  taken.  When  the  unit  becomes  operational,  the  internally 
generated  heat,  aging  and  other  factors  will  cause  some  drift  away  from 
the  components  design  value.  This  can  cause  the  factory  level  readings  to 
become  marginal  although  the  unit  still  performs  properly  in  the  system. 

This  drift  is  a normal  occurrence,  and  should  be  allowed  for  in  the  design. 
The  design  tolerance  and  the  design  proof  testing  should  attempt  to  deter- 
mine how  far  the  unit  can  drift  away  from  the  design  tolerance  and  still 
perform  as  intended  in  its  next  higher  assembly.  This  design  proof  type  of 
testing  should  not  be  carried  throughout  the  higher  levels,  but  it  all  too 
often  is.  This  results  in  unnecessary  rejection  of  operational  units. 


4.5  TESTABILITY 


The  most  important  ingredient  to  a successful  test  program  is  something 
that  must  take  place  long  before  the  development  begins.  That  ingredient 
is  the  testability  of  the  unit  to  be  tested. 

The  importance  of  a unit  being  designed  to  be  tested  has  been  mentioned 
previously,  and  cannot  be  over-emphasized.  The  test  program  cannot 
improve  the  testability  of  the  unit.  It  can  only  take  what  has  been  made 
available  and  develop  the  best  possible  program  from  that. 

Every  piece  of  electronics  equipment  that  has  ever  been  constructed  can 
be  tested  in  some  manner  and  to  some  extent.  How  extensive  that  test  can 
be  depends  in  part  on  how  accessible  that  equipment  is  to  the  tester.  If 
it  is  impossible  to  get  to  the  internal  devices,  it  is  still  possible  to  perform 
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some  type  of  test  using  only  the  input/output  signals  that  are  available  in 
the  system  configuration.  This  does  allow  the  system  function  to  be  tested, 
but  may  require  simulation  of  the  other  portions  of  the  system  to  perform 
essentially  a hot-mock-up-type  of  test.  In  some  cases,  this  can  be  an 
adequate  test. 

If  the  system  configuration  signals  are  all  that  are  available,  it  does  make 
the  use  of  automatic  test  equipment  and  automatic  test  programs  more 
difficult.  It  generally  means  very  complex  interface  devices  are  required, 
and  even  with  the  complex  ID,  no  meaningful  fault  isolation  would  be 
possible.  This  is  true  at  both  the  LRU  and  SRU  levels,  but  as  stated  before, 
if  this  is  all  that  is  required,  there  is  dertainly  no  need  to  incur  the  addi- 
tional expense  involved  in  developing  a truly  testable  device. 

If,  however,  a thorough  test  with  fault  isolation  to  small  component 
groups  is  required,  it  is  necessary  to  provide  access  to  the  internal  compo- 
nents. In  the  case  of  an  LRU,  these  components  would  be  the  SRU's  that 
make  up  the  LRU.  Critical  signals  that  allow  groups  of  SRU's  to  be  isolated 
from  each  other,  signals  that  allow  functions  to  be  separated,  signals  that 
assist  in  the  evaluation  of  the  operability  of  the  device  - must  all  be  pro- 
vided to  the  tester  through  the  use  of  test  points  or  test  connectors.  In  the 
case  of  SRU's,  large  numbers  of  components  on  a card  with  limited  I/O  may 
appear  attractive  to  the  mechanical  packager,  but  it  is  not  very  conducive 
to  the  test  program  development  effort.  Large  multi -function  circuit  boards 
make  the  task  of  isolation  to  small  component  groups  very  difficult  without 
the  use  of  extensive  probing.  This  is  never  desirable.  It  increases  the  test 
setup  time,  the  test  run  time  and  can  result  in  an  unreliable  program. 

The  above  items  are  problems  that  occur  after  the  program  has  been  developed. 
The  problems  that  must  be  faced  during  the  development  period  are  problems 
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that  can  extend  the  development  time  to  unreasonable  lengths.  Some  of 
these  problems  are: 

o The  designing  of  complex  interface  devices, 
o Selection  of  proper  probe  points, 
o Routing  the  probe  points  into  the  tester, 
o Determining  the  proper  probe  to  use. 
o Initialization  of  digital  circuits, 

o Component  isolation  in  feedback  loops. 

These  problems  can  for  the  most  part  be  avoided  if  the  device  to  be  tested 
was  designed  to  be  tested  by  allowing  internal  access,  by  allowing  the  test 
equipment  to  control  direct  set  and  reset  lines,  by  allowing  feedback  loops 
to  be  broken,  but  they  must  be  designed  in.  They  cannot  be  added  by  the 
test  program  developer.  He  can  only  take  what  has  been  made  available 
to  him,  and  depending  on  the  required  isolation  level,  design  the  inter- 
face device  and  add  the  probe  points  necessary  to  achieve  the  specified 
isolation  ambiguity. 

Testability  has  recently  been  receiving  a considerable  amount  of  discussion 
by  the  ATE  industry,  but  has  not  yet  received  the  necessary  emphasis  by 
the  electronic  equipment  manufacturer.  Until  the  proper  emphasis  is 
placed  on  it  at  the  designer's  level,  the  problems  the  test  program  devel- 
oper must  face  will  continue  with  the  result  being  long  and  costly  test 
programs  with  less  than  the  desired  level  of  isolation. 
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The  Testability  Checklist  is  formatted  in  a way  that  allows  a yes  or  no 
Grower  for  each  of  the  items.  It  is  not  intended  to  make  a UUT  more 
testable  because  at  this  point  in  the  development  cycle  the  design  is 
beyond  this.  The  checklist  is  intended  to  provide  the  test  program 
developer  with  some  visibility  as  to  just  how  testable  the  UUT  is. 
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FIGURE  4.1 

TESTABILITY  CHECKLIST 


Line  Replaceable  Unit 


No 

Built  in  test  (GO-  NO  GO)  

Built  in  test  (Isolation)  

Test  connector  (s)  provided  

Static  test  acceptable  

Clock  control  provided  

Initialization  capability  

Common  module  connector  type 
Replaceable  large  sub-assemblies  (P.S.) 

Plug-in  modules  

Test  information  provided  by  manufacturer  

Input/Output  devices  compatible  with  tester  

Test  points  buffered  


Yes 
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TESTABILITY  CHECKLIST  (Confd) 


Shop  Replaceable  Unit 


Can  feedback  loops  be  interrupted 

Can  memory  elements  be  initialized 

Complex  elements  (I  e. , UARTS  & microprocessors) 
mounted  in  sockets 

External  clock  control 

Long  buss  lines  interruptable 

Test  points  buffered 

Can  long  counter  chains  be  broken 

Wired  OR's  minimized 

Clearly  identified  components 

Sufficient  component  mounting  clearance  for  attaching 
test  clips 

Test  information  provided  by  manufacturer 
Input/Output  devices  compatible  with  tester 
Module  keying  defeatable 


IV- 17 


4.6  DATA  REQUIREMENTS 


The  data  required  to  develop  functional  and  diagnostic  LRU  and/or  SRU 
test  programs  for  automatic  test  is  divided  into  three  (3)  categories: 

/ 

o UUT  Supplier  Data 
o TPS  Development  Data 
o Deliverable  (User)  Data 

4.6.1  UUT  Supplier  Data 

The  UUT  source  documentation  defines  the  UUT  operating  characteristics 
and  performance  requirements  and  generally  comprises  the  following: 

o UUT  Design/Performance  Specification. 

o Factory  and  Operational  Maintenance  Test  Procedures, 

Technical  Manuals,  and  other  related  documentation. 

o Schematics,  Wiring  Diagrams,  Manufacturing  Drawings,  etc. 

If  the  source  information  completely  represents  a current  and  complete 
definition  of  test  requirements,  then  the  test  design  engineer  can 
proceed  with  TPS  design.  However,  if  sufficient  current  data  is  not 
available,  the  data  must  be  generated  through  design  analysis,  bench 
testing  and/or  other  techniques  appropriate  to  the  UUT.  Regardless 
of  the  source  used,  UUT  performance  requirements  must  be  defined  and 
documented  prior  to  detailed  test  design.  The  test  design  engineer 
cannot  effectively  generate  an  accurate  and  complete  test  without 
guidance  in  the  area  of  UUT  performance.  Without  proper  performance/ 
failure  mode  data,  the  actual  support  requirements  of  the  UUT  may  never 


IV— 18 


be  fully  appreciated.  Testing  based  on  inadequate  data  may  fall  short 
of  UUT  support  objectives  in  the  field,  or  could  well  result  in  testing 
too  stringently  and  result  in  an  unduly  high  rejection  rate.  In  practice, 
when  dealing  with  developmental  UUT's,  the  source  documentation 
package  is  often  incomplete  and/or  in  a state  of  flux.  This  necessitates 
the  requirement  for  formal  documentation  change  control.  Each  subse- 
quent documentation  change  must  take  into  account  software  impact  and 
its  relationship  to  the  test  program  effort. 

The  list  of  specific  data  required  is: 

o Schematics/Logic  Diagrams 
o Assembly  Drawings 
o Parts  Lists 

o Component  Specifications  Control  Sheets 
o Producti  on/ Acceptance  Test  Procedures 

o Compatibility  Reports  (Description  of  Operation) 

o Photographs 

o Critical  Initialization  Procedures 

o Test  Patterns  (I/O  Sequences) 

o Wiring  Diagrams/Pin  Lists 

o Signal  Waveforms  and  Timing  Diagrams 
o Manual  Adjustment  Procedures 

o Power  Supply  Voltage  and  Current  Requirements 

o Cooling  Requirements 

o Loading  Requirements 
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4.6.2  TPS  Development  Data 


During  test  program  development,  a TPS  data  package  is  developed  which 
is  the  sole  receptical  of  all  design/development  information  during  program 
development  and  also  a complete  history  of  the  development  process.  This 
data  package  is  utilized  for  monitoring  test  development  progress  and 
management  control  throughout  the  life  of  the  TPS.  Thus,  at  the  completion 
of  the  test  development  program,  a completely  current  TPS  design  data  package 
is  available  consisting  of  the  following: 

o Diagnostic  Flowcharts  (DFC)  - The  step-by-step  flow  of 
the  test  program.  The  flowchart  is  generated  from  the  List 
Requirements  Documents  and  is  used  as  the  "outline"  for 
generating  the  code. 

o Fault  List  - A list  of  possible  failures  that  can  occur  in 
the  Unit  Under  Test  (UUT).  The  list  can  be  used  to  select 
faults  to  verify  the  test  program  if  that  method  of  program 
verification  is  used. 

o Component  Checklist  - A list  of  all  components  on  an 

SRA  showing  the  failure  modes.  To  be  used  to  verify  that 
a test  was  written  to  detect  that  mode  of  component  mal- 
function. 

o Probe  Point  Designations  on  Assembly  and  Schematic 
Drawings  - Probe  points  that  are  selected  by  the  test 
program  developer  to  aid  in  the  isolation  of  a failure 
are  shown  on  these  drawings. 

o Non-Ambiguity  Ratio  Calculations  - The  calculations 
that  show  the  number  of  failure  messages,  and  the 
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number  of  components  in  each  failure  message  that 
could  possibly  contribute  to  the  malfunction. 

Non-Detectables/Non-Functionals  List  - A list  that 
indicates  those  components  that  if  a certain  type  of 
failure  occurs,  such  as  one  resistor  in  a parallel  resis- 
tance network  open,  the  failure  cannot  be  detected 
using  normal  test  methods. 

Select-At-Test  Components  Handling  Documents  - 
The  information  that  details  the  parameters  to  be 
observed,  and  the  type  and  range  of  components  to 
be  used  in  the  selection  process. 

Circuit  Analysis  Work  Sheets  - The  work  sheets 
used  by  the  test  program  developer  in  the  analysis 
phase  of  the  development.  The  sheets  are  useful 
if  changes  are  required  later  in  the  development 
process,  and  if  changes  in  the  UUT  configuration 
take  place  after  the  program  is  operational. 

Functional  Block  Diagrams  - Block  diagrams  that 
show  the  functional  operation  of  the  UUT  which  can 
be  useful  in  helping  to  determine  if  a functional  or 
static  test  is  required. 

Interface  Device  (ID)  Design  Data  - The  interface 
device  design  data  details  the  information  required  to 
build  the  ID. 

Program  Listing(s)  - The  listing  of  the  test  program 
that  contains  the  detailed  test  information  that  results 
from  the  code  and  compile  phase  of  the  development. 


* ' - •«. 


o Test  fVogram  Instruction  (TPI)  - The  information 
required  by  the  test  operator  to  set  up  and  execute 
the  test  program  is  contained  in  the  test  program 
instructions.  Information  such  as  cautions  and  warn- 
ings, probe  point  details,  and  select-at-test  require- 
ments should  also  be  included  in  this  document.  1 

4.6.3  Deliverable  Data 


During  normal  operational  use,  the  ATE  technician/operator  requires  a 
minimal  amount  of  information  to  enable  him  to  perform  the  test  program. 
The  operator  must  first  have  a means  erf  identifying  and  accessing  the 
proper  configuration  information.  The  data  must  then  provide  him  with 
necessary  instructions  for  interfacing  the  UUT  and  the  test  program  with 
the  tester  and  the  instructions  to  carry  the  test  to  its  proper  conclusions. 

Maintenance/Test  fVogram  supplementary  data  in  the  form  of  UUT  to 
tester  interface  drawings,  and  test  description  information  may  be  pro- 
vided to  facilitate  on-station  (ATE)  troubleshooting  and  ambiguity  group 
breakdown . 

Deliverable  data  will  include: 

o Test  fVogram  Instructions  (TPI ’s) 

o Program  Listing(s) 

o ID  Design  Data  - 

Top  Assembly  Drawing 
Nameplate  Drawing 
Layout  Drawing 
Wire  List($) 
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o Test  Program  Tape/Disc  (TPT/D) 

o Master  Test  Program  Set  Index  (MTPSI) 

o Maintenance  Support  Data  - 

Test  Interconnection  Diagrams 

Circuit  Schematic  (Functional  Flow) 

Make  from  Instructions  (Parts  Modification) 

Description  and  Theory  of  Operation  in  LRU 
Test  Descriptions 
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SECTION  V 

CODE  AND  COMPILE 


In  the  past,  software  generation  has  been  treated  as  a secret  art  of  select 
software  specialists.  This  is  no  longer  the  case;  in  fact,  the  best  software 
can  be  generated  by  an  experienced  test  engineer  whose  ability  spans  both  test 
techniques  and  an  understanding  of  the  ATE  language.  The  test  program  design 
should  include  the  following  elements  to  reduce  the  total  development  costs: 

o Hardware/Software  Interface  Reference  Material 
o Test  Program  Instructions  (TPI) 

o Code  and  Compile  Techniques 

This  section  discusses  the  procedures  required  to  reduce  the  code  and  compile 
development  to  a cost  effective  technique  and  to  provide  meaningful  test 
documentation  for  the  site  user. 
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REFERENCE  MATERIAL 

The  selected  ATE  User's  Guide  should  be  reviewed  to  determine  whether  it 
contains  the  following  criteria.  If  not,  it  will  be  necessary  to  summarize 
certain  data  for  quick  reference  and  usage  during  code  and  compile  and  on- 
station  testing. 

The  software  language  should  be  described  for  each  mode  of  tester  operation, 
showing  the  required  field  and  options  which  must  be  filled  in  during  the  coding 
operation.  On  the  same  page  or  following  page,  the  ATE  pins  on  which  each 
signal  appears  should  be  available  and  must  be  summarized  to  avoid  the  need  of 
referring  to  other  documents.  These  are  best  described  by  simple  block  diagrams 
showing  the  input  and  output  pins  and  the  software  fields  which  are  related  to 
each  pin.  In  addition,  descriptions,  using  the  same  format,  should  be  made  for 
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an/  special  interface  devices  described  in  the  previous  sections.  Where 
large  interface  connectors  are  used,  a matrix  diagram,  showing  pin 
numbers  and  related  ATE  functions,  should  be  made. 

5.2  TEST  PROGRAM  INSTRUCTIONS  (TPI) 

The  information  for  the  Test  Program  Instruction  is  prepared  by  the  test 
programmer,  but  the  ultimate  user  is  the  tester  at  the  site.  The  Test  Program 
Instructions  (TPI's)  should  be  formatted  and  a simple  checklist  prepared  for 
the  programmer  to  fill  in.  This  will  standardize  the  TPI  and  reduce  the 
language  barrier  between  the  programmer  and  the  technical  writing  group. 
Working  with  the  TRD,  the  programmer,  can  block  out  the  operator  actions 
required  to  connect  the  setup,  load  the  program  and  run  the  test,  thus 
minimizing  the  time  required  to  prepare  the  TPI,  if  it  were  saved  to  the 
last. 

Operator  Action  messages  may  be  prepared  in  advance,  thus  eliminating 
errors  caused  in  a two-step  operation.  Simple  test  diagrams  should  be 
prepared  for  each  setup  to  enhance  the  understanding  of  the  UUT/ATE 
operation.  These  sketches  may  become  a part  of  the  final  TPI  to  aid  in 
test  diagnostic  troubleshooting. 

5.3  CODE  AND  COMPILE  TECHNIQUES 

Code  and  Compile  procedures  can  be  simplified  by  preparing  standard 
messages  and  routines  in  advance.  These  procedures  should  be  appended 
to  the  reference  material  described  in  Section  10.1 . A brief  descriprion 
of  some  of  the  techniques  which  should  be  included  are: 

o Standard  Messages 
o Structured  Programmi  ng 
o Annotation 
o Entry  Poi  nts 
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5.3.1  Standard  Messages 


Standard  messages  should  be  prepared  to  reduce  preparation  time  required  for 
individual  systems.  These  should  include,  as  a minimum,  initial  setup  and 
configuration  check,  pass/fail,  adjustments,  often-used  operator  actions,  and 
advisories.  These  messages  should  use  standard  spacing  for  easy  reading.  If 
variable  fields  are  required,  the  standard  message  may  be  prepared  as  a sub- 
routine with  the  variables  being  passed  on  as  arguments.  It  can  also  be 
prepared  on  a standard  coding  form,  with  blank  fields  for  the  programmer  to 
insert  the  correct  variables. 

5.3.2  Structured  Programming 

Standard  procedures  should  be  prepared  for  uniform  structuring  of  the  program. 
Using  the  TRD  as  an  outline,  the  general  test  flow  and  coding  strategy  can  be 
determined.  Types  of  tests  and  test  connections  can  be  grouped  into  categories. 
Standard  subroutines  can  be  prepared.  Some  often-used  procedures  can  be 
modularized  and  compiled  into  many  programs  with  proper  software  procedures 
for  a given  compiler.  Since  the  finished  program  listing  should  be  a part  of  the 
documentation,  the  use  of  subroutines  should  consider  the  visibility  of  the 
completed  form.  Is  it  readable?  Are  nested  routines  required?  Does  the  compiler 
print  out  a concordance?  These  answers  will  determine  the  extent  to  which 
subroutines  can  be  used  without  masking  the  test  flow  from  the  test  user. 

5.3.3  Annotation 

The  coded  listing  should  be  annotated  with  comment  cards  to  assist  the  tester 
in  identifying  the  test  against  the  TRD.  Comment  cards  can  be  prepared  during 
the  intital  test  planning  and  will  form  an  in-line  table  of  contents  for  the  tests. 
Test  numbers  should  be  sequential  with  allowance  made  for  revisions.  For  - 
example,  test  should  progress  in  tens,  with  diagnostic  branches  having  some 
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relation  to  the  functional  test  from  which  it  branched.  The  display  should 
use  annotations  to  advise  the  operator  of  the  general  test  section  which  is 
being  run. 


5.3.4  Entry  Points 


Entry  points  should  be  placed  at  the  beginning  of  each  major  test  series. 
The  use  of  entry  points  must  consider  the  need  for  safe-to-tum-on  and 
initialization  procedures.  These  should  be  clearly  annotated  in  the  TPI. 
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SECTION  VI 

6.0  INTERFACE  DEVICE  (ID)  DESIGN 

The  Interface  Device  (ID)  design  requirements  are  determined  by  the  UUT 
functional  requirements  (Section  4)  and  the  ATE  Characteristics,  This  section 
will  discuss  the  steps  necessary  to  generate  the  ID  design. 

The  items  to  be  discussed  in  this  section  include: 

1 . Level  of  complexity 

2.  Self  test  requirements 

3.  UUT  protection 

4.  Mechanical  considerations 

5.  ID  checklist 

6.1  LEVEL  OF  COMPLEXITY 

The  UUT  functional  interface  requirements  described  in  Section  4 will  determine 
the  size  and  complexity  of  the  ID.  UUT  signal  characteristics  are  itemized 
pin-by-pin,  including  the  electrical  characteristics,  such  as  voltage,  impedance, 
frequency,  rise  time,  etc.  The  number  and  types  of  signals  are  then  summarized, 
including  the  maximum  number  of  simultaneous  signals  for  each  signal  type.  This 
summary  should  be  made  without  regard  to  the  ATE  to  be  used.  Terminology 
should  be  compatible  with  the  test  flow  diagram  prepared  as  part  of  the  Test 
Requirement  Document  (TRD).  The  ID  check  list  will  group  these  requirements  as 
inputs/outputs  from  the  UUT  for: 

o Grounds  and  shields 

6 Power  requirements 

o Analog  stimulus/response 

o Digital  stimulus/response 

o Timing  and  control 
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o Probing  requirements 

o Special  requirements 

The  UUT  input/output  summary  is  then  compared  to  the  ATE  signal  charac- 
teristics described  in  Section  10  to  determine  full  compatibility.  Where  I/O 
does  hot  match,  additional  analysis  must  be  made  to  determine  the  most  cost 
effective  method  of  matching  the  requirements  by  adding  elements  in  the  ID. 

ID  complexity  will  be  minimized  by  the  use  of  ATE  with  universal  switching 
interface. 

ID  elements  may  include  switches,  relays,  buffers,  amplifiers,  registers,  etc., 
and,  if  necessary,  SRU  circuitry  from  the  parent  UUT  to  achieve  full  compatibility. 
In  extremely  complex  cases,  the  design  should  consider  the  use  of  common 
complex  IDs  to  satisfy  a family  of  UUT  requirements.  In  the  case  of  simple  IDs, 
every  attempt  should  be  made  to  utilize  the  same  ID  for  several  UUTs. 

The  cost  of  the  complex  design  and  subsequent  self-test  requirements  must  be 
traded  off  with  the  cost  and  utilization  of  more  sophisticated  ATE.  Such  trade- 
offs must  consider  the  high  logistic  cost  of  a manual  test  alternative  which  would 
require  more  personnel  and  training  throughout  the  life  cycle.  The  use  of  a 
standard  ATE  data  bus  will  allow  cost  effective  design  of  special  requirements  in 
a common  ID  which  is  controlled  by  the  standard  ATE. 

6.2  SELF  TEST  REQUIREMENTS 


ID  Self  Test  is  mandatory  on  even  the  simplest  ID.  If  the  usage  of  the  test 
equipment  is  high,  experience  has  shown  that  self  test  will  save  time  in  all 
phases  of  development  and  site  usage.  This  is  due  in  part  to  the  wear  out  of 
mating  connectors.  All  active  signals  should  be  wrapped  around  so  that  all 
sources  are  activated  into  every  measurement  device  used  by  the  system.  The 
order  of  priority  should  be  as  follows: 


o Internal  (to  ID)  wraparound  without  disconnecting  UUT 
d Minimum  swapping  of  external  connectors 
o Wraparound  shorting  plug  substituted  for  the  UUT 

All  self  test  techniques  should  avoid  removing  any  ATE  interface  connectors 
whenever  possible  as  this  could  cause  undetected  mating  problems  during  the  test. 

6.3  UUT  PROTECTION 

The  UUT  functional  characteristics  should  include  requirements  for  protection 
of  the  UUT  against  damage  by  the  ATE  or  vice  versa  during  turn  on/off  and 
transient  conditions.  Power  sources  should  be  designed  to  crowbar  in  case  of 
malfunction.  It  may  be  necessary  to  design  certain  protective  circuitry  in  the 
ID,  such  as  voltage  limiters  on  voltage  sources  to  TTL  circuits. 

6.4  MECHANICAL  CONSIDERATIONS 

The  mechanical  configuration  of  the  interface  device  is  determined  by: 
o Number  of  input/output  connectors 

o Amount  of  signal  conditioning  required  for  ATE  compatibility 
o Cooling  requirements  for  UUT  and/or  ID 
o Holding  fixtures  required  for  UUT 

Physical  size  should  be  minimum  so  that  handling  and  storage  problems  are 
minimized;  however,  a 20%  expansion  capability  should  be  provided  for  in 
the  initial  design. 

Any  signal  conditioning  circuitry  within  the  ID  should  be  modular  in  construction 
and  readily  accessible  via  access  doors. 
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Captive  cabling  should  be  minimized  where  general  purpose  cabling  can 
be  provided. 

6.5  ID  CHECKLIST 

Table  6.1  is  an  ID  checklist  for  summarizing  all  requirements  for  the 
design  review.  The  checklist  should  be  updated  as  changes  are  required 
to  maintain  complete  visibility  of  the  design. 


TABLE  6.1 


INTERFACE  DEVICE  CHECKLIST 


Number  of  signals 
Digital 
Analog 
Power 


Special  signal  wiring  required  0 .e. , twisted  pair,  coax 
shielded  wire) 

Digital  quantity  ^ 

Analog  quantity  

Power  quantity 


Buffering  required 

Digital  quantity 
Analog  quantity 

Signal  conversion  required 
Digital  quantity 
Analog  quantity 

Special  timing  required 
Digital  quantity 
Analog  quantity 


Speoial  control  required 
Digital  quantity 
Analog  quantity 


INTERFACE  DEVICE  CHECKLIST  (Cant'd) 


ID  power  requirements 

ftobe  requirements 

ID  self-test  required 

UUT  removal  required  for  self-test 

UUT  electrical  protection  required 

UUT  cooling  required 

ID  cooling  required 

UUT  holding  fixture  required 

Common  ID  feasibility  evaluated 

General  purpose  cabling  evaluated 


Access  to  ID  active  components  evaluated 


j 
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7.0  INTEGRATION 

The  integration  of  the  test  program  requires  the  bringing  together  of  all 
the  previously  developed  pieces  to  verify  that  the  test  strategy  was 
prrper,  the  interface  device  design  is  as  required,  the  test  set  is  ade- 
quate and  the  test  program  instructions  are  correct. 

The  integration  process  simply  stated  is  to  verify  that  the  test  program 
will  pass  a good  unit-  reject  a bad  unit  and,  if  rejected,  determine  the 
cause  of  failure. 

Prior  to  the  first  test  on  the  ATE,  a safe-to-operate  procedure  should  be 
prepared  to  check  all  power  lines  and  avoid  damage  to  the  ATE  in  case 
of  ID  wiring  errors.  The  next  phase  would  be  a manual  step  through  of 
each  test  to  determine  at  a deliberate  speed,  that  each  test  is  properly 
coded  and  that  the  UUT  is  responding  to  the  test  commands.  When  this 
is  complete,  a functional  test  can  be  run  with  a known  good  UUT.  The 
program  is  then  forced  down  each  major  diagnostic  branch  to  insure  that 
all  coding  is  correct.  The  remaining  checks  will  consist  of  fault  simula- 
tion and  fault  insertion.  The  number  and  method  of  simulating  faults  is 
a major  contributor  to  integration  costs.  It  is,  therefore,  important  to 
trade  off  the  number  of  faults  against  the  program  ambiguities  in  the 
final  analysis. 
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During  the  course  of  test  program  set  development,  formal  design  reviews 
between  the  TPS  contractor  and  supplier  should  be  accomplished* 


Experience  has  shown  that  two  (2)  formal  reviews  ere  required  and  con  be 
referred  tp  as  Preliminary  and  Critical. 

8.1  REVIEW  FORMAT 

The  TPS  supplier  technical  representative  and  the  contracting  agency 
representative  should  jointly  chair  the  meeting. 


The  supplier  should  present  an  overview  of  the  TPS  to  familiarize  all 
attendees  with  the  test  philosophy  and  strategy. 

During  this  presentation,  the  contracting  agency  representative  should  be 
adding  or  deleting  questions  from  a list  which  has  been  pre-prepared  having 
reviewed  the  data  prior  to  the  design  review. 

At  the  conclusion  of  the  supplier  presentation,  the  contracting  agency 
should  address  his  list  of  questions  until  mutual  satisfaction  is  reached. 

Detailed  minutes  of  the  design  review  should  be  recorded  and  any  open 
action  items  should  be  summarized  and  responsibili ties/ schedules  assigned 
for  closure. 

Action  item  closure  reports  should  be  prepared  with  a detailed  description 
of  the  corrective  action  taken. 
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Mutual  concurrence  of  action  item  disposition  should  be  required  prior  to 
commencing  TPS  debug  and  validation. 


8.2  PRELIMINARY  DESIGN  REVIEW  (PDR) 

The  PDR  should  be  conducted  upon  completion  of  test  analysis  which 
results  in  a detail  flowchart  and  adapter  requirements  definition. 

Items  to  be  reviewed  are  indicated  in  the  checklist  Figure  8.0—1 . 


8.3  CRITICAL  DESIGN  REVIEW  (CDR) 

The  CDR  should  be  conducted  at  the  completion  of  TPS  debug/verifi cation. 
Any  anomalies  revealed  during  this  review  also  require  action  item  closure 
reports  prior  to  the  conduct  of  the  TPS  Acceptance  Demonstration. 

The  product  of  this  CDR  should  be  a mutually  agreeable' set  of  tests  which 
will  demonstrate  the  ability  of  the  TPS  to  diagnose  the  UUT  and  isolate 
failures. 

8.4  CHECKLIST 

The  design  review  checklist  is  purposely  structured  to  accommodate  both 
PDR  and  CDR  in  single  document.  The  checklist  should  be  an  integral 
part  of  a permanent  engineering  data  book  assembled  by  the  TPS  develop- 
ment engineer  and  maintained  throughout  the  total  development  process. 

Figure  8.0-1  suggests  an  itemized  list  of  checks  to  assure  a proper  review. 
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DESIGN  REVIEW  CHECKLIST 


Figure  8.0-1 


UUT  DATA 


Nomenclature 
Part  Number 
Drawings: 

Schematic 
Assembly 
Parts  List 


Test  Specification 


TEST  DESIGN  DOCUMENTS  AND  MATERIALS 
AVAILABILITY 


PDR  Items: 

1 . UUT  Drawings: 

a)  Schematics 

b)  Assembly 

c)  Parts  List 

d)  Test  Specification 

2.  UUT  Engineering  Analysis  Summary 

3.  Interface  Adapter  Sketches 

4.  Detailed  Flowchart  (DFC) 

CDR  Items: 

1 . All  PDR  Items 

2.  Source  Code  Usting 

3.  Formal  Adapter  Drawings 

4.  Final  DFC 

5.  Final  Source  Code  Listing 

6.  Recommended  Spare  Parts  List 


Yes  No 


Figure  8.0-1  (Cont'd) 


UUT-ATE  INTERFACE  DEFINITION 

Yes 

No 

A. 

PDR  Items: 

1. 

Determination  of  I/O  Signals  & Power  Reg. 

2. 

ATE  capable  of  providing  I/O  & Power 

3. 

Adapter  requirements  determined 

4. 

Mechanical  sketches  conform  to  requirements 

5. 

Proposed  adapter  conforms  to  negotiated  basic  design 

B. 

CDR 

Items: 

1. 

Formal  adapter  drawings  agree  with  PDR 

2. 

Formal  drawings  complete  and  accurate 

3. 

Final  DFC  fully  tests  UUT 

4. 

Final  source  code  listing  reflects  DFC 

TEST  STRUCTURE  EVALUATION 

Yes 

No 

A.  PDR  Items: 

1 . Engineering  Analysis  Summary 

a. 

Circuit  analysis  complete 

b. 

Test  parameters  guarantee  operation  at  next 

higher  assembly 

c. 

ATE  tolerances  calculated  for  each  test 

d. 

ATE  tolerances  ratio'd  with  circuit 

specification  tolerances 

e. 

Ratios  10%  for  all  tests 

2.  DFC 

a. 

All  UUT  functions  fully  verified 

b. 

Reflects  circuit  analysis 

c. 

FVobing  reviewed 

d. 

SAT  procedures  are  accurate 

e. 

Grounding  is  adequate 

f. 

Tolerances  are  same  as  engineering 

analysis  definitions 
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Figure  8.0-1  (Cont'd) 


Yes  No 


CDR  Items: 


TPS  listing  test  numbers  conform  to  DFC 
test  numbers 

TPS  listing  accurately  represents  DFC 
All  displays  are  using  standard  message  format 
Test  Program  Instruction  (T PI)  test  numbers 
conform  to  DFC  & ATLAS  listing  test  numbers 
TPI  contains  accurate  test  setup  instructions 
T3I  contains  clear  SAT  instructions 
Spare  parts  list  accurate 


SUMMARY 


Yes  No 


PDR  Items: 

1 . Engineering  analysis  summary  complete 

2.  Adapter  requirements  complete 

3".  DFC  complete 

4.  Action  item  no.  , , 

CDR  Items: 

1 . TPS  source  code  complete 

2.  Formal  adapter  drawings  complete 

3.  Final  DFC  complete 

4.  TPI  complete 

5.  Action  item  no.  , , 

Deliverable  items  complete 


COMMENTS  AND  NOTES 


PDR  Date 
CDR  Date 


PDR  OK 
CDR  OK 


Test  Engineer 


Test  Engineering  Manager 
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SECTION  IX 


9.0  ACCEPTANCE  TESTING 


The  most  important  factor  to  be  evaluated  in  the  acceptance  test  of  a 
Test  iYogram  Set  is  to  evaluate  its  accuracy  and  usability.  There  are 
only  three  functions  of  the  TPS  and  they  are  as  follows: 


o Correctly  identify  a "good"  UUT. 
c Correctly  identify  a Tsad"  UUT. 
o Correctly  identify  the  "cause"  of  a UUT  failure. 


The  inability  of  a TPS  to  perform  these  functions  can  generally  be 
attributed  to  the  following: 


Inappropriate  use  of  test  techniques. 
Improper  test  limit  derivation. 

Improper  ordering  of  tests. 

Incomplete  testing. 

Incorrect  or  unclear  operator  instructions. 
Unidentified  interface  device  failure. 
Improper  application  of  the  test  system. 


Acceptance  testing  should  concentrate  on  both  usability  and  accuracy  of 
the  TPS. 
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9.1  FINAL  DESIGN  REVIEW 


If  structured  properly,  the  final  design  review  should  serve  as  a tool  in 
identifying  areas  of  potential  weakness  of  the  TPS.  Test  techniques, 
overall  test  strategy  and  the  testing  sequence  should  be  carefully  reviewed 
from  a functional  block  diagram  of  the  (JUT.  The  interface  device  should 
be  reviewed,  and  if  complex,  the  adequacy  of  the  self  test  reviewed. 

It  should  be  verified  that  all  functions  of  the  UUT  are  tested  and  several 
of  the  test  limit  derivations  explained.  The  application  of  each  different 
function  of  the  test  system  used  should  be  evaluated.  The  operator 
instructions  should  be  reviewed  for  clarity  and  the  program  documentation 
evaluated  as  to  the  use  of  making  a program  change.  If  all  of  the  above 
items  are  reviewed,  a better  confidence  in  the  TPS  quality  can  be  gained. 


9.2  DEMONSTRATION 


! 
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The  demonstration  of  the  test  program  set  is  the  final  check  of  its  quality 
prior  to  being  used  in  an  actual  military  test  and  repair  environment. 

It  is  here  that  the  UUT  will  be  exercized  by  the  TPS  on  the  test  system. 

It  is  recommended  that  two  (2)  UUT's  be  used  for  this  demonstration. 

This  will  allow  a better  observation  on  the  adequacy  and  accuracy  of 
the  test  tolerances . 

A better  measure  of  the  clarity  of  the  operating  instructions  will  be 
gained  if  the  cognizant  procurement  engineer  that  participated  in  the 
final  design  review  actually  runs  the  TPS. 

It  is  suggested  that  a small  team  of  test  engineers  select  the  faults  for 
each  UUT.  This  fault  list  should  be  based  on  the  recommendations  of 


— 
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the  Final  design  review  and  also  concentrate  on  faults  that  have  a higher 
probability  of  occurring  in  the  UUT.  The  number  of  faults  selected  should 
be  directly  proportional  to  the  number  of  failure  modes.  The  UUT  should 
be  restored  after  each  fault  with  the  TPS  verifying  the  repair  of  the  UUT. 
It  is  the  opinion  of  the  authors  that  the  number  of  faults  inserted  not  be 
large,  with  penalties  added  for  each  missed  fault.  A suggested  penalty 
measure  might  be  as  follows: 


Faults  Correctly  Isolated 


< 75% 


Penalty 

Fix  missed  faults,  add  1 
penalty  fault  per  miss. 

Fix  missed  faults,  add  2 
penalty  faults  per  miss. 

Fix  missed  faults,  add  3 
penalty  faults  per  miss. 


If  more  than  one  test  system  is  available,  the  TPS  should  be  run  on  two 
different  systems. 


9.3  DELIVERABLE  DATA 


All  data  generated  during  the  generation  of  a test  program  set  should  be 
considered  as  deliverable  data.  The  test  program  tape/disc,  operating 
instructions,  interface  device  and  drawings,  program  listing  and  UUT  data 
are  the  usual  items  considered  as  deliverable  data.  Other  data  such  as 
design  review  minutes  and  notes  and. the  engineering  notebooks  and  flow- 
charts are  invaluable  when  doing  maintenance  on  the  test  program  itself. 


— 
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A well  annotated  listing  can  be  sufficient  for  maintenance  if  done  as 
a stand  alone  document,  but  a specification  has  never  been  generated 
to  assure  that  the  listing  will  contain  the  necessary  technical  strategy 
and  maintenance  information. 

9.4  WARRANTY 

Once  the  TPS  has  been  demonstrated  and  sold  off,  the  contractor  usually 
has  no  responsibility  to  fix  errors  that  are  discovered.  Rather  than  have 
an  extensive  formal  demonstration,  a warranty  period  imposed  on  the 
contractor  would  quite  likely  produce  a better  overall  product.  It  would 
force  more  thorough  internal  technical  reviews  and  minimize  the  cost  of 
overall  software  maintenance. 


SECTION  X 


ATE  CONSIDERATIONS 


Automatic  Test  Equipment  (ATE)  design  and  testability  should  be  treated  in 
the  same  manner  as  the  operational  electronics  it  was  designed/selected  to 
suppprt.  The  ATE  must  be  designed  for  versatility,  reliability  and  main- 
tai nobility.  ATE  hardware  and  software  design  considerations  which  impact 
total  operational  life  cycle  costs  are: 

o ATE  Standardization 

o ATE  Expandability 

o ATE  Availability 

o Human  Factors 

o Documentation 

10.1  ATE  STANDARDIZATION 

The  operational  electronics  level  of  repair  (LOR),  discussed  in  Section  II, 
concluded  that  no  single  ATE  could  satisfy  all  testing  requirements  for  medium 
or  large  electronic  systems.  A suite  of  ATE  will  be  required  to  satisfy  all 
testing  requirements  at  the  Operational,  General  Support,  Depot  and  Factory 
levels.  Each  ATE  subsystem  should  be  selected  with  the  maximum  commonality 
within  cost  constraints. 

10.1.1  ATE  LOR  Considerations 


At  the  Organizational  Level  (O-Level),  higher  availability  will  be  achieved 
by  expedited  fault  isolation  and  modular  replacement  using  Built-In-Test  (BIT). 
Portable  ATE  (eontact  testers)  would  result  in  less  ambiguity  in  O-Level  test- 
ing and,  in  some  cases,  allow  isolation  to  the  SRU  level.  The  ATE  at  the 
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Organizational  Level  should,  therefore,  depend  on  the  Operational  Electronics 
MTTR  requirements,  including  the  feasibility  of  O-Level  spare  parts.  At  the 
General  Support  Level  (GS-Level),  an  ATE  of  . odular  design  using  common 
equipment  from  an  approved  list  will  be  configured  for  support  of  commodity 
oriented  equipment,  such  as  communications-electronics,  missiles  and  avionics. 
Starting  at  the  GS-Level,  ATE  commonality  with  the  Depot  and  Factory  Repair 
levels  is  a feasible  and  cost-effective  goal.  A common  core  tester,  such  as 
the  AN/USM-410  ()V  should  be  selected  for  LRU  and  SRU  testing  at  GS-Level. 
Using  MIL-STD-1513  to  predict  ATE  work  load,  a given  GS  installation  can 
be  equipped  with  ATE  augmented  for  RF,  digital  or  hybrid  testing  of  both  LRU's 
and  SRU's. 

When  very  complex  LRU's  are  tested  at  GS-Level,  long  tests  times  (run  time) 
should  be  avoided  by  better  testability  and  BIT  to  improve  MTTR  and  reduce 
the  quantity  of  ATE  at  the  site.  Available  spare  modules  will  determine  the 
extent  on-line  module  swapping  will  be  feasible  to  reduce  the  logistic  pipe- 
line. Manual  operations  and  adjustments  in  ATE  testing  decrease  station 
throughput.  LRU's  with  excessive  adjustments  should  be  off-loaded  to  manual 
testers  or  general  purpose  ATE  designed  to  enhance  operation  and  adjustment 
techniques. 

Depot  Level  ATE  should  overlap  the  GS-Level  design,  but  include  test  capability 
of  low  failure  LRU's  and  SRU's  to  minimize  the  vendor  repair  requirements. 

Work  load  predictions  will  determine  initial  implementation.  Future  expansion 
will  depend  on  the  ease  of  software  development  which  can  be  accomplished 
usi  ng  local  manpower.  This  requirement  enhances  the  need  for  a common  easily 
programmed  language  such  as  ATLAS. 

The  vendor  repair  level  should  contain  the  tightest  tolerance  test  capability 
and  should  be  designed  to  electrically  simulate  the  Depot  and  GS-Level  test 


interface.  It  is  usually  not  feasible  to  require  the  vendor  to  use  the 
standard  ATE. 

10.1 .2  ATE  Performance  Characteristics 


Table  A shows  the  performance  characteristics  of  the  AN/USM-410  ()V 
Equate  tester  and  the  expanded  capabilities  with  the  augmented  RF  and 
universal  switching  modules.  A comparison  of  these  capabilities  against 
the  operational  electronics  test  requirements  will  determine  the  addi- 
tional test  requirements  which  must  be  developed  or  supported  with 
additional  support  equipment.  The  natural  tendancy  in  the  past  has 
been  to  purchase  the  vendor's  PGSE  which  runs  up  the  life  cycle  costs 
with  additional  documentation  and  training  and  creates  specialists  which 
may  not  be  utilized  to  a full  time  assignment.  The  ATE  design  should 
lend  itself  to  expansion  to  cover  these  situations,.  On  the  other  hand, 
an  expensive  computer  operated  tester  should  not  be  used  when  a simple 
volt-ohmmeter  and  a continuity  chart  can  do  the  job. 

Most  ATE  consists  of  a basic  computer  and  peripherals  to  control  and 
observe  the  testing  of  the  UUT.  The  remaining  two  sections  are  the  ATE 
interface  and  the  building  blocks.  The  building  blocks  (BB's)  are  signal 
stimulus  response  monitoring  equipment,  power  supplies  and  switching 
which  perform  the  testing  that  is  processed  by  the  computer.  These  BB's 
may  be  stcfidard  test  equipment  or  synthesizers  such  as  those  contained 
in  a third  generation  ATE  such  as  the  AN/USM  -410.  In  comparing  the  BB 
usage  against  the  operational  electronics  requirements,  some  BB's  are  not 
required  and  should  be  eliminated  unless  the  cost  of  elimination  would  be 
prohibitive  limit  expansion  capabilities.  Low  usage  BB's  can  be  built  into  the 


; * 


Interface  Device  (ID)  if  cost  effective,  thus  keeping  the  basic  ATE  costs  down. 

A solution  to  added  test  requirements  and  future  expansion  capabilities  is  the 
addition  of  a standard  data  bus  interface  to  the  ATE. 


10.1.3  Program  Language 

The  standard  program  language  should  be  ATLAS.  It  is  an  established  language 
which  is  easily  converted  to  ATE  machine  code.  The  ATE  should  have  on-line 
edit  capability  to  reduce  UUT  integration  costs.  Safeguards  should  be  included 
to  insure  configuration  control  of  software.  The  software  should  allow  for  the  use 
of  Automatic  Test  Program  Generation  (ATPG)  such  as  LASAR  and/or  guided 
probe.  The  software  should  be  modular  for  easy  expansion  and  documentation  should 
be  included  in  the  programming  manual  to  assist  the  TPS  engineer  in  development 
of  new  test  programs. 
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ATE  Hardware  Design 
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The  ATE  should  be  ruggedized,  but  not  MIL  standard  to  reduce  costs.  Human 
factors  should  be  a major  consideration  in  the  layout  for  efficient  operation  of 
the  UUT.  The  AN/USM-410  has  a work  surface  for  the  UUT  which  enhances  its 
utility.  The  documentation  should  cross  reference  software  functions  and  interface 
pins  for  quick  identification  for  the  operator  and  the  TPS  designer. 


The  ATE  interface  is  the  most  critical  cost  item  in  the  selection  of  test  require- 
ments. Some  of  the  elements  which  impact  cost  are: 

o Dedicated  pins  vs.  universal  switching 

o Performance  characteristics  vs  universal  switching 
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o Number  of  pins 

o Interface  connector  design  and  reliability 

o LRU  vs  SRU  interface  requirements 

Dedicated  pins  to  the  stimulus  and  response  functions  of  the  ATE  generally  result 
in  the  need  for  a unique  interface  device  (ID)  to  route  signals  to  the  proper  pins 
for  each  UUT.  If  testability  was  a design  consideration  in  the  development  of 
the  operational  electronics,  fewer  connector  types  will  be  required,  resulting  in 
some  UUT's  sharing  the  same  ID.  If  the  ATE  has  universal  switching  so  that  any 
function  can  be  connected  to  any  interface  pin,  multiplexing  of  UUT's  on  a 
single  ID  will  greatly  reduce  production  and  maintenance  costs.  The  performance 
trade-off  when  using  universal  switching  is  caused  by  distributed  capacity  and 
other  characteristics  which  degrade  signal  performance. 

This  trade-off  is  a greater  concern  in  the  case  of  LRU's  over  the  SRU's.  Dedicated 
high  speed  digital  RF  signals,  UUT  power  and  low  level  measurement  pins  will  be 
required  in  ATE  systems  with  universal  switching. 

Good  testability  requirements  in  the  development  of  electronics  will  avoid  added 
complexity  in  the  ID's.  If  signal  conditioning  is  required,  the  cost  of  ID  design 
and  production  costs  is  increased  in  the  order  of  one  to  ten  hours  per  pin.  If,  for 
example,  a system  to  be  used  has  low  level  differential  digital  logic  instead  of 
the  standard  TTL,  many  buffers  would  be  required  and  additional  self  test  circuitry 
would  further  increase  costs.  A standard  auxiliary  interface  device  designed  to 
convert  the  non-standard  logic  for  up  to  six  (6)  LRU's  and  provide  control  using 
the  standard  data  bus  to  the  ATE  computer  would  provide  a cost-effective  design 
for  this  situation.  This  approach  would  be  advisable  to  increasing  the  ATE  inter- 
face requirements  for  six  (6)  LRU's  or  for  each  new  non-standard  situation. 
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The  number  and  design  of  the  ATE  interface  pins  is  a major  cost  item.  The 
number  of  mating  operations  may  be  as  high  as  5000  per  year.  A rugged  design 
which  is  easily  repaired  is  desirable.  Wear-out  adapters  can  be  considered, 
but  must  not  degrade  interface  signal  characteristics.  When  the  ATE  interface 
exceeds  one  hundred  pins  or  has  a large  number  of  coaxial  pins,  the  connector 
costs  increase  exponentially.  This  is  caused  by  the  need  to  use  a few  pins  on 
each  interface  connector.  Large  quick  disconnect  connectors  are  a viable 
solution  if  standard  interface  auxiliary  devices  are  designed  for  adapting  special 
cases  to  the  ATE. 

The  interface  requirements  for  LRU's  and  SRU's  are  quite  different.  LRU  require- 
ments in  general  require  higher  power,  more  active  digital  processing  and  more 
modulation  techniques.  SRU  requirements  need  less  power,  more  loads  and 
matching  devices,  require  a lower  pin  count.  Most  ATE  utilize  an  auxiliary 
interface  device  to  adapt  the  device  for  SRU  usage.  Another  approach  is  to 
consider  augmenting  the  ATE  with  table  top  digital  testers  to  support  large 
quantities  of  static  digital  test  for  SRU's.  This  alternative  must  be  trade-off 
with  the  use  of  bus  controlled  specialty  testers  which  can  take  advantage  of  the 
ATE  software  system's  full  capability  including  automatic  test  program  generation 
(ATPG). 

10.2  ATE  EXPANDABILITY 


Table  B shows  the  predicted  expansion  in  ATE  characteristics  which  will  be 
required  in  the  next  five  and  ten  years.  Existing  ATE  will  require  that  the 
computer  interface  bus  be  connected  to  a standard  instrumentation  data  bus  to 
provide  expansion  capability  for  future  growth.  Three  recommended  data  buses 

are: 

MIL-STD-1397 
MIL-STD-1553  or  1553A 
IEEE  STD  488 
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Wi  th  a standard  data  bus  interface,  the  core  ATE  can  be  kept  to  a minimum 
with  special  test  requirements  and  expansion  connected  via  the  data  bus  to  the 
ATE  computer.  The  same  standard  data  bus  can  be  used  at  the  vendor  repair 
level  to  simulate  Depot  and  GS  interface  requirements  without  the  use  of 
the  basic  ATE. 

ATE  AVAILABILITY 


ATE  Availability  is  computed  in  the  same  manner  as  the  UUT: 

Availability  = MTBF 

MTBF  + MTTR  • 

High  reliability  is  essential.  MTTR  includes  time  to  detect,  isolate  and  repair 
the  ATE.  MTTR  becomes  more  critical  if  only  one  ATE  is  located  at  the  site. 
MTTR  for  ATE  can  be  minimized  by  acquiring  test  systems  with  self-check 
(confidence  test)  and  self-test  (diagnostics)  capability.  Self-check  capability 
of  ATE  should  be  implemented  by  operator  command  without  removal  of  any 
elements  of  the  system  and  should  run  automatically  in  less  than  fifteen 
minutes.  In  case  of  ATE/UUT  ambiguities,  an  interface  signal  wraparound 
test,  using  a shorting  plug  should  be  included  in  the  extended  self-check 
test  to  eliminate  the  ATE  as  the  source  of  error.  Self-check  should  identify 
the  BB  which  has  failed  and  should  be  keyed  to  extended  testing  of  the  failed 
BB  using  self-test. 

Self-test  should  be  possible  without  physically  removing  units  from  the  ATE 
system.  Those  elements  of  the  ATE  which  will  virtually  down  the  system  when 
failures  occur  should  have  adequate  spare  modules  to  insure  a minimum  of  one 
hour  turnaround  in  the  repair  cycle. ' When  practical,  environmental  specifica 
tions  for  ATE  should  be  relaxed  to  permit  use  of  commercially  available, 
ruggedized  ATE  systems. 
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ATE  support  equipment  should  be  acquired  with  the  ATE  to  provide  rapid 
repair  capability  of  ATE  modules  at  the  site. 

10.4  ATE  HUMAN  FACTORS 

ATE  requirements  should  consider  human  factors  as  they  impact  station 
operating  costs.  Some  considerations  which  the  design  must  provide  are: 

o Quick  setup/tear-down  time 

o Optimized  man-machine  interface  for  controls,  monitors,  etc. 

o Easily  operated  control  instructions 

o Efficient  work  space  for  the  unit  under  test  (UUT) 

o Built-in  status  monitoring  and  emergency  power  shutdown 

in  case  of  catastrophic  faults 

o Standard  Mnemonics  to  reduce  operator  errors  between  both 

software  and  hardware 

o Quick  recall  of  self-check  (confidence)  test  capability 

o Minimum  utilization  of  self-test  (diagnostic  test)  require- 

ments to  remove  ATE  equipment  from  the  system  for  fault 
isolation 

10.5  ATE  DOCUMENTATION 


ATE  documentation  should  be  easily  interpreted.  The  performance  specifications 
at  the  interface  should  be  tabulated  for  quick  reference.  Internal  performance 
characteristics  may  be  shown  in  reference,  but  should  be  clearly  identified  if 
there  is  system  degradation  due  to  the  interface.  The  most  important  feature 
should  be  a single  volume  for  programming  and  determining  performance  character- 
istics expended  when  developing  test  programs.  This  feature  should  relate  directly 
to  the  Test  Requirement  Documents  (TRD's)  developed  for  each  UUT. 
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The  quality  control  provisions  of  the  ATE  specification  should  demonstrate 
full  system  performance  during  the  first  article  testing  and  adequate  sampling 
of  critical  tests  for  subsequent  production  acceptance  tests  for  all  ATE 
systems. 
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Type 


Digital 


Analog 


Hybrid 


Cost  (K$) 


Computer  Model  No . 


Manufacturer 


Memory  Size 


Compiler 


Test  Rrogram 


Magnetic  Tape 
Other 


Program  Storage  Medium 


Paper  Tape Disk Card 


Test  Language 
On-Line  Edit 


Interface 


Type 


Dedicated 

Universal 

Power 


Stimulus 


Quantity 


Measurement 
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ATE  CHECKLIST  (Cont'd.) 


TABLE  A 
FIGURE  10.2 

AN/USM-410  QV  PERFORMANCE 


STIMULUS 

DC-Signal 


DC-Standard 


AC-Power 


AC-Signal 


Dual  Pulse  Generator 


Synchro 


RF  Source 
Digital 


2 ea  0 to  + 60V  @ 4A 

1 ea  0 to  + 28V  @ 5A 

2 ea  0 to  + 36V  @ 9A 

1 ea  0 to  + 36V  @ 25A 

1 ea  0 to  + 500V  @ 0.4A 

1 ea  0 to  + 1000V  @ 0.2A 

0-1  li.1 11VDC  +0.001  V 
+ 0.003 %/6  mo 

0-130VRMS/  50V A 1 or  3 phase 
45-10KHZ 

20  VP-P  into  50  OHM 
Sinewave  .015  to  6 MHZ 
Squarewave  .015  to  3 MHZ 
Trianglewave  .015  to  3 MHZ 
Sawtooth  .015  to  3 MHZ 
Complexwave  .015  to  3 MHZ 

50  NS  to  655.36  SEC 
0-20  VP-P  into  50  OHMS 
Rise/Fall  25  NS  to  0.5  SEC 

3 Wire  to  1 1 .8  V RMS  L-L  @ 400  HZ 
0-360  DEC  0.02  Steps 

60  KHZ  - 500  MHZ 

32  Bit  Parallel  Word  Gen/Rec 


TABLE  A (Cont'd) 


MEASUREMENT 

DC  Voltage  and  Ratio 

AC  RMS  Voltage  and  Ratio 

AC  Peak  Voltage 

Waveform  Analysis 

Frequency 

Period 

Time  Interval  (Dual  Channel) 
Rise  or  Fall  Time  & Pulse  Width 
Phase  Angle 
Synchro  Angle 
Impedance 
Transfer  Function 
Harmonic  Distortion 
Harmonic  Analysis 


100  UV  to  200  VDC,  0.1% 

0 - 140  V RMS,  0.5%  - 4% 

0 - 200  VP,  0.5%  - 4% 

DC  - 300  MHZ, +4% 

DC  - 500  MHZ 
100  NS  to  200  SEC 
20  NS  to  2000  SEC 
20  NS  to  2000  SEC 
0.2  HZ  to  10  MHZ,  + 180° 

0 - 360°,  0.2° 

10  OHM  to  100  K MEGOHM , + 4% 

0 - 175  V RMS,  DC  - 20  MHZ,  0 - 360° 

50  MV  to  140  V RMS,  +3% 

2 HZ  - 300  MHZ,  - 40  DB,  + 0.8  DB 


TABLE  A (Cont’d) 


INTERFACE 


Dedicated  Pins  Stimulus  and  Responses  (DIU) 
Two  Coax  Relays 
32  Switches 

frogrammable  Interface  (PIU) 

128  Input/Output  Pins 
128  Measurement  Only  Pins 
2 Probes 

RF  SUBSYSTEM 


Stimulus 

60  KHZ  to  500  MHZ  - 1 17  to  + 10  DBM 
500  MHZ  to  18  GHZ  - 105  to  + 5 DBM 
AM  and  Pulse  Modulation 

Measurement 

Power  10  MHZ  to  18  GHZ  - 35  DBM  to  + 30  DBM 

Frequency  10  HZ  to  18  GHZ 

Spectrum  Analysis  10  MHZ  to  18  GHZ 

AM  & FM  Demodulation 

Complex  Impedance  110  MHZ  to  18  GHZ 

VSWR  or  Reflection  Coefficient 


Signal  Processing 

Attenuation  0 to  127  DB  DC  to  1 GHZ 
0 to  110  DB  DC  to  18  GHZ 
Delay  10  NS  to  10  MICROSEC 
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TABLE  B 


FIGURE  10.3 

FUTURE  ATE  REQUIREMENTS 


PARAMETER 

5 Years 

10  Years 

FREQUENCY 

40  GHZ 

100  GHZ 

FREQ  HOPPING 

20-  10  K 

20  - 10  K 

HOPS/SEC 

HOPS/SEC 

DIGITAL  LOGIC 

• 100  MBPS 

1 GBPS 

DISTRIBUTED  PROCESSING 

MSI 

LSI 

OPTICAL/IR 

30  MBPS 

100  MBPS 

SEISMIC 

— 

0.1  - 1000HZ 

' 

0.1  - lOOg 

SECTION  XI 


n.O  CONFIGURATION  MANAGEMENT 

11.1  CAPABILITIES 

The  Configuration  Management  System  required  for  test  programs  requires 
the  classic  techniques  of  identification,  control  and  accounting.  This 
system  defines  the  procedures,  forms  and  data  elements  necessary  to  provide 
the  foundation  upon  which  effective  configuration  control  is  based.  The 
system  delineates  the  overall  requirements  and  provides  a unified  approach 
to  configuration  management.  The  "system"  not  only  satisfies  the  require- 
ments of  contractual  obligations,  but  provides  for  any  need  of  large-scale 
system-type  programs  and  further  ensures  a total  support  point  of  view. 

11.2  ORGANIZATION 

The  direction  and  coordination  of  the  effort  described  in  this  section  is 
the  responsibility  of  the  Configuration  Manager,  under  the  functional 
direction  of  the  Program  Manager.  The  tasks  required  to  comply  with 
this  procedure  will  be  accomplished  within  the  existing  Project  Organiza- 
tion structure  by  the  Configuration  Manager.  The  various  functions  such 
as  Engineering,  Manufacturing,  Material,  Support  Services,  and  Quality 
Assurance  are  coordinated  by  the  Configuration  Manager  to  assure  compliance. 

11.3  ENGINEERING  CHANGE  CONTROL 

There  must  be  established  a formal  Configuration  Control  Board  to  maintain, 
control  and  evaluate  changes  to  contractual  technical  requirements;  released 
design,  quality  assurance,  maintenance;  and  hardware  to  assure  that  such 
changes  are  authorized  and  actually  incorporated  in  any  hardware  developed, 
i.e..  Interface  Devices,  reflected  in  all  affected  data,  and  compliant  with 
requirements.  The  Configuration  Control  Board  is  operated  on  a continuation 
basis  during  the  development  phase  of  the  program. 
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11.4  DRAWINGS 

Engineering  Drawings  required  for  the  test  program  adapters  should  be 
prepared  in  accordance  with  the  requirements  of  MIL-D-1000,  MIL- 
D-100,  Form  3. 

11.5  SPECIFICATION  AND  ENGINEERING  DATA  RELEASE 

Engineering  drawings,  specifications  and  standards  used  to  define  the 
configuration  of  each  article  should  be  released  for  the  purpose  of 
formally  establishing  an  approved  engineering  document.  The  "release" 
is  indicated  by  the  data  control  release  signature  and  date  appearing  on 
the  reproduced  documents. 

11.6  CONFIGURATION  MANAGEMENT  OF  SOFTWARE 

For  purposes  of  configuration  management,  computer  software  programs 
are  defined  as  a punched  or  magnetic  deck  of  cards,  tapes  or  other  physical 
medium  containing  a sequence  of  instructions.  Punched  or  magnetic  card 
decks  and  computer  tapes  for  deliverable  computer  programs  are  delivered, 
accepted  and  managed  as  a Configuration  Item  product. 

11.7  SOFTWARE  PROGRAM  IDENTIFICATION 
Identification  of  Computer  Software  Programs  is  as  follows: 

a.  The  band  or  case  of  each  deck  should  be  marked  with 
the  part  number  of  the  deck  and  the  design  activity 
code  identification  number. 

b.  The  outside  end  of  each  computer  tape  should  be  marked 
or  punched  for  direct  visual  interpretation  of  its  complete 
item  identification  and  part  number  and  design  activity 
code  identification  number.  The  same  information  should 

appear  on  the  tape's  reel  and/or  cannister. 
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11.8  COMPUTER  PROGRAM  CONTROL 

The  aspects  of  the  computer  program  which  are  subject  to  configuration 
management  are: 

a.  The  physical  form  dimensions,  and  materials  of  the 
tape  or  card  deck  medium. 

b.  The  actual  sequence  and  content  of  the  instructions 
and  data. 


11.9  ENGINEERING  SOFTWARE  CHANGE  PROCESSING 

Changes  to  computer  programs  are  processed  for  approval  in  the  same 
manner  as  changes  to  drawings  or  hardware. 

11.10  SOFTWARE  DOCUMENTATION 

Identification  of  Software  Documentation  - The  following  guidelines  should 
be  used  to  identify  and  aid  in  control  of  all  items: 

a.  Perforated  Tape  - The  outside  end  of  each  tape  should  be 
punched  with  part  number  and  revision  letter  such  that 
direct  visual  identification  is  readily  obtained. 

b.  Card  Decks  - Boxes  of  cards  should  be  clearly  marked 
with  proper  part  number  and  revision  letter.  Cards 
within  a box  should  be  numberically  sequenced  so  that 
incomplete  decks  can  be  detected. 

c.  Listings  - Each  page  of  the  listing  should  be  marked  as 
to  proper  part  number  and  revision  letter.  Pages  should 
be  numerically  sequenced  so  that  incomplete  listings  can 
be  detected. 

d.  Program  Flow  Diagrams  - Flow  diagrams  and  user  hand- 
books should  be  maintained  in  the  same  manner  as  a hard- 
ware configuration  drawing.  The  documents  should  contain 
part  numbers  and  proper  revision  letter  and  further  contain 
cross  reference  to  applicable  computer  program  configurations. 
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